Relatório Avaliação da Candidatura da Livraria Online do Teatro Nacional D. Maria II

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

Lista de evidências recolhidas:

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

  etiqueta: chk 10 webetiqueta: melhoriaetiqueta: R 1.2

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

  • Ver requisito 1.2 da lista 10 aspetos

  O sub-menu não deve abrir automaticamente quando tem o foco das tecnologias de apoio, para não tornar obrigatória a sua leitura antes de ir para a próxima opção.

  No código, é necessário implementar um evento que permita ao atributo aria-expanded mostrar ou esconder as subopções. Recomenda-se criar um evento de clique que irá abrir ou fechar o sub-menu de acordo com o estado da opção do 1º nível.

  As melhorias devem garantir:

  • Que as opções de 1º nível do menu fiquem colapsadas até o utilizador escolher aceder às subopções com a tecla “Enter”.
  • Que as opções de 1º nível colapsem quando o foco do teclado não está numa delas.
  • Que seja possível sair das subopções com a tecla “Escape”.

  Para garantir esse comportamento, as opções de 1º nível do menu de navegação devem ter:

  • O atributo ARIA aria-expanded para as tecnologias de apoio identificarem que existem subopções e quando o menu está colapsado (aria-expanded=”false”) ou expandido (aria-expanded=”true”).
  • O atributo ARIA aria-current para as tecnologias de apoio identificarem estruturalmente em qual das opções do menu é que o utilizador se encontra.

  Para mais informação sobre boas práticas de implementação dos menus e submenus, podem consultar a página da W3C.

  

  Figura 1 - Ao testar o menu principal com o leitor de ecrã VoiceOver, verificou-se que, quando o foco está na primeira opção com submenu e se carrega na seta para baixo, o leitor de ecrã entra nesse submenu em vez de passar para a opção principal seguinte.

• evidência: Falta de Indicação Visual Clara para Submenus no Menu Principal

  etiqueta: chk 10 webetiqueta: melhoriaetiqueta: R 1.2

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

  • Ver requisito 1.2 da lista 10 aspetos

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

Lista de evidências recolhidas:

• evidência: O logótipo principal da homepage tem um link para a própria página

  etiqueta: chk 10 webetiqueta: melhoriaetiqueta: R 2.1

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

  • Ver requisito 2.1 da lista 10 aspetos

  Na homepage, o logótipo principal deve estar sem hiperligação para não direcionar o utilizador para a página onde já se encontra. Já nas páginas interiores, o logótipo principal já pode ter um link para a homepage.

  No site da Livraria Online do Teatro Nacional D.Maria II, o logótipo principal da homepage tem um link para a própria página (ver Figura 1).

  Recomendamos que seja retirado o link atualmente atribuído ao logótipo na página principal, mantendo esse link nas restantes páginas interiores. Nestas, o texto alternativo do logotipo deve ser, por exemplo, alt=”Ir para a página principal da Livraria Online do Teatro Nacional D. Maria II”.

  

  Figura 1 - Página inicial da Livraria Online do Teatro Nacional D. Maria II na qual o logótipo reencaminha para a própria página.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: Ausência de cabeçalhos estruturados em tabela

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

  As tabelas de dados devem identificar o seu conteúdo com elementos semânticos adequados para que os leitores de ecrã consigam referenciar corretamente os cabeçalhos e identificar a tipologia dos dados de cada coluna e linha. No caso dos cabeçalhos das tabelas, estes devem estar marcados com o elemento <th>.

  A modal que incorpora o carrinho de compras, na página Textos de Teatro, contém uma tabela para especificação dos produtos no carrinho de compras. Nesta tabela, os elementos <th> estão presentes mas são utilizados para apresentar dados — como o título do produto — em vez de servirem como cabeçalhos de coluna (Figura 1). Isso dificulta a leitura da tabela por parte dos leitores de ecrã, que dependem dos cabeçalhos para interpretar corretamente o conteúdo de cada célula.

  Recomendamos que seja adicionado um elemento <thead> com células <th> que descrevam cada coluna dos cabeçalhos — como, por exemplo, “Imagem”, “Produto”, “Quantidade”, “Preço” e “Ação”. As células de dados devem ser inseridas dentro de um <tbody>, utilizando células do tipo <td>. Recomendamos também remover o símbolo “x” das células que indicam a quantidade, para evitar confusão na leitura por tecnologias assistivas.

  Sugestão de possível código a implementar:

  <table>
    <caption>Lista de compras</caption>
    <thead>
      <tr>
        <th>Imagem</th>
        <th>Produto</th>
        <th>Quantidade</th>
        <th>Preço</th>
        <th>Ação</th>
      </tr>
    </thead>
    <tbody>
      <tr>
        <td>
  
  <!-- IMAGE_PLACEHOLDER_0 -->
  
  </td>
        <td>A cacatua verde</td>
        <td>1</td>
        <td>9,50€</td>
        <td><button aria-label="Remover o livro A cacatua verde">❌</button></td>
      </tr>
      
      <tr>
        <td>
  
  <!-- IMAGE_PLACEHOLDER_1 -->
  
  </td>
        <td>A constituição</td>
        <td>1</td>
        <td>10€</td>
        <td><button aria-label="Remover o livro A constituição">❌</button></td>
      </tr>
    </tbody>
  </table>
  

  

  Figura 5 - Código da tabela do carrinho de compras inspecionado através do Google Inspector. Elementos <th> destacados com contorno vermelho.

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

Lista de evidências recolhidas:

• evidência: Tabela sem legenda visível

  etiqueta: chk 10 webetiqueta: melhoriaetiqueta: R 3.2

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

  As tabelas de dados devem ter uma legenda ou título marcado com o elemento de forma a dar um maior contexto e ajudar a associar rapidamente a tabela ao seu conteúdo.

  Verificámos que a tabela que especifica os produtos e que integra a modal do carrinho de compras na página Textos de Teatro, possui uma legenda(“Lista de compras”) que está oculta para todos os dispositivos exceto leitores de ecrã.

  Recomendamos remover a classe sr-only do elemento <caption> para que a legenda também seja exibida visualmente.

  

  Figura 1 - Código relativo à legenda da tabela dentro da modal do carrinho de compras. A classe sr-only esconde a legenda de todos os dispositivos exceto leitores de ecrã.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: As mensagens de erro são exibidas uma de cada vez

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 4.3

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

  As mensagens de erro são exibidas uma de cada vez. Embora seja possível apresentar apenas uma mensagem por submissão, esta abordagem pode dificultar a compreensão do que necessita de ser corrigido, especialmente quando existem múltiplos campos com erros. Ao mostrar apenas uma mensagem, o utilizador pode não identificar todos os problemas de forma clara e eficiente.

  No formulário de Registo de Conta de Cliente, as mensagens de erro são apresentadas junto ao campo. No entanto, quando existem vários campos com erros de preenchimento, apenas uma mensagem é exibida de cada vez. Por exemplo, se sete campos obrigatórios não estiverem preenchidos — “NIF”, “Código postal”, “País”, “Distrito”, “Senha”, “Confirmar senha” e "Por favor, complete a validação" —, ao submeter o formulário, apenas a mensagem de erro do campo NIF será apresentada. Isto impede que o utilizador identifique os restantes sete campos obrigatórios não preenchidos, uma vez que não existe qualquer mensagem a indicar quais são (Figura 1).

  

  Figura 1 - Formulário de Registo de Conta de Cliente com vários campos obrigatórios por preencher(“NIF”, “Códigos postal”, “País”, “Distrito”, “Senha”, “Confirmar senha” e "Por favor, complete a validação") e apenas é apresentada uma mensagem de erro associada a “NIF”.

  As mensagens de erro devem estar sempre visíveis para o utilizador, independentemente de o campo estar ou não em foco. Recomenda se rever o formulário para garantir que cada campo com dados incorretos ou por preencher apresente a respetiva mensagem de erro junto a si. Na primeira submissão, todas as mensagens de erro devem ser apresentadas em simultâneo, permitindo ao utilizador identificar e corrigir todos os problemas de uma só vez. Uma solução eficaz é criar um elemento de mensagem de erro específico para cada campo e associá lo a esse campo através do atributo aria-describedby.

  Para mais informações sobre boas práticas na colocação de mensagens de erro em formulários, pode ser consultada a página da WAI sobre Notificações para utilizadores.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: As imagens decorativas dos cards contêm texto alternativo que repete a informação do card

  etiqueta: chk 10 webetiqueta: melhoriaetiqueta: R 5.1

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

  No caso das imagens dos cards(cartões) que sejam acompanhadas de texto, devem ser consideradas como decorativas e não funcionais. Sendo assim, o seu texto alternativo deve ser nulo ou devem ser adicionadas como background-image em CSS.

  Na página Textos de Teatro existem cards com imagem e texto, nos quais os links associados às imagens possuem texto alternativo. O leitor de ecrã, ao ler o card, repete a informação “A Cacatua Verde” duas vezes, pois está colocada no link do card e no título da imagem.

  É possível observar que o card contém:
  • Texto alternativo no link: aria-label="A cacatua verde"
  • O rótulo na imagem: <strong>A cacatua verde</strong>

  Para evitar que o leitor de ecrã repita várias vezes a mesma informação, as imagens dos cards devem ser consideradas como decorativas e colocado o texto alternativo nulo da seguinte forma: (alt=””). Outra forma é adicionar as imagens via CSS.

  Para esta situação, deve-se também utilizar a técnica do link esticado, garantindo assim que o leitor de ecrã lê a informação relevante apenas uma vez.

  

  Figura 1 - Leitor de ecrã lê título de cada livro duas vezes. Primeiro, através do texto alternativo associado à imagem-link do livro e depois no texto que contém o título do livro.

• evidência: As imagens funcionais não possuem um texto alternativo

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 5.1

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

  As imagens funcionais devem incluir um texto alternativo que sirva de síntese do seu propósito e que seja lido pelo leitor de ecrã.

  Na página inicial existem imagens não decorativas sem texto alternativo, por exemplo:

  • No carrossel “Em Destaque”, as setas de navegação (esquerda e direita) não possuem texto alternativo que indique a sua função.

  • No rodapé, na secção “Contactos”, são usados ícones isolados para representar as diferentes formas de contacto com a Livraria (morada, telefone, e-mail e site do Teatro) mas nenhum destes ícones tem texto alternativo.

  

  Figura 1 - Seta de navegação do carrossel "Em Destaque" analisada através do ANDI e do Google Inspector. Sem texto alternativo.

  

  Figura 2 - Ícone de rodapé indicativo da morada da Livraria sem texto alternativo.

  Recomendamos a revisão das imagens não decorativas para que incluam um texto alternativo, através do elemento aria-label. Por exemplo, no caso das setas de navegação do carrossel “Em Destaque”, um possível texto alternativo poderia ser “Produto anterior” (no caso da seta para a esquerda) e “Produto seguinte” (no caso da seta para a esquerda).

etiqueta: N/A

Lista de evidências recolhidas:

• evidência: R 5.2 - 10 Aspetos

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

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

  Não há representações complexas no site que necessitem de uma descrição longa.

etiqueta: N/A

Lista de evidências recolhidas:

• evidência: R 7.1 - 10 Aspetos

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

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

  Não foram encontrados players de vídeo dentro do domínio do site.

etiqueta: N/A

Lista de evidências recolhidas:

• evidência: NA

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

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

  Não foram encontrados players de vídeo dentro do domínio do site.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: Existem conteúdos repetidos em HTML quando se remove o CSS

  etiqueta: chk 10 webetiqueta: melhoriaetiqueta: R 8.2

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

  Ao desativar o CSS da página Privacidade, é possível observar que o bloco de texto principal aparece duplicado no final da página (Figura 1). Este problema não ocorre apenas nesta página — em várias outras páginas do site, o mesmo bloco de texto também é exibido no final do documento HTML quando o CSS está desativado (Figura 2).

  Recomendamos que este bloco duplicado seja removido do código HTML para evitar lixo informático.

  

  Figura 1 - Parte final da página Privacidade com o CSS desativado.

  

  Figura 2 - Parte final da Página Inicial com o CSS desativado.

• evidência: Existem conteúdos repetidos em HTML e que são lidos apenas por tecnologias de apoio

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 8.2

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

  Na página inicial, quando se retira o CSS, logo no início da página e a seguir ao link “Saltar para Conteúdo”, existe uma hiperligação “Mapa do site” que é lida por leitores de ecrã (Figura 1). Esta hiperligação para a página Mapa do Site já está presente no rodapé do site na lista não ordenada por baixo de “Serviços ao cliente”(Figura 2).

  Recomendamos que a hiperligação “Mapa do site”, que é lida pelos leitores de ecrã logo no início da página (Figura 1), seja removida para evitar lixo informático e para que as tecnologias de apoio, nomeadamente leitores de ecrã, não a leiam repetidamente.

  

  Figura 1 - Página inicial com o CSS desativado. Hiperligação "Mapa do site" não está visível na interface mas é lida por leitores de ecrã.

  

  Figura 2 - Hiperligação "Mapa do Site" visível no rodapé do site.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: Existem elementos com a semântica incorreta (Calendário)

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 8.3

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

  Na página Pedidos de Devolução, foi identificado que o widget de calendário não segue uma estrutura semântica adequada.

  Ao testar este componente com um leitor de ecrã, verificámos que a navegação por teclado dentro da janela modal do calendário não está devidamente implementada. Não é possível navegar entre os dias do calendário utilizando as setas de direção do teclado, nem percorrer apenas os elementos interativos através das teclas Tab e Shift + Tab.

  Constatámos também que o foco não fica restrito à modal do calendário – é possível continuar a navegar com o teclado por outros elementos do site, mesmo com o calendário aberto (Figura 1).

  

  Figura 1 - Apesar de a modal de calendário estar aberta, é possível continuar a navegar por outros elementos do site.

  As setas de navegação existentes dentro do calendário, usadas para avançar ou recuar entre meses, não apresentam indicação visual clara da sua função e não possuem descrição alternativa que permita às tecnologias de apoio — como leitores de ecrã — comunicar corretamente o seu propósito ao utilizador.

  Adicionalmente, o componente não transmite qualquer informação sobre o seu estado – não comunica quando a janela modal do calendário é aberta (expandida) nem quando é fechada (recolhida).

  Para mais informações sobre como desenvolver um widget de calendário acessível, recomendamos a consulta do recurso Date Picker Dialog Example da W3C.

• evidência: Existem elementos com a semântica incorreta (Cards)

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 8.3

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

  Nas páginas de venda de produtos — como a página Textos de Teatro — verificámos que a estrutura dos cartões de produto não segue uma estrutura semântica adequada.

  Tal como referido anteriormente no ponto 5.1 da Checklist dos 10 Aspetos Funcionais, as imagens dos produtos têm o mesmo texto alternativo no link da imagem — elemento <a> — e no texto que apresenta o nome do livro, o que faz com que o leitor de ecrã anuncie duas vezes o nome do livro. Recomendamos que a fotografia do produto seja tratada como uma imagem decorativa e que seja colocado um texto alternativo nulo (alt=””) ou que seja adicionada a imagem via CSS.

  Em produtos em promoção, como por exemplo no livro “A Farsa de Inês Pereira”, o leitor de ecrã anuncia o preço promocional e o preço original seguidos e sem contexto (“10,80€ 12,00€"), o que pode ser confuso para quem está a navegar pela página através de leitor de ecrã (Figura 1).

  

  Figura 1 - Página Textos de Teatro onde nos produtos em promoção, como no livro " A Farsa de Inês Pereira", o preço promocional e o preço original são lidos de seguida e sem contexto.

  Uma solução seria editar o texto por forma a indicar visualmente, e para tecnologias de apoio, qual é o preço promocional e qual é o preço original. Por exemplo, “Preço promocional: 10,80€” e “Preço original: 12,00€”. Em alternativa, outra solução seria adicionar dois comandos, através da classe .sr-only, para informar utilizadores de leitor de ecrã que o primeiro valor corresponde ao preço promocional (<span class="sr-only">Preço promocional:</span>) e o segundo ao preço original do produto (<span class="sr-only">Preço original:</span>).

  Para mais informações podem consultar o modelo Stretched link do Bootstrap 5.

• evidência: Existem elementos com a semântica incorreta (Carrossel)

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 8.3

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

  Existem elementos com a semântica incorreta

  Os elementos da página devem estar identificados com a semântica de HTML certa para que sejam interpretados corretamente pelas tecnologias de apoio.

  Carrossel
  Ao inspecionar o carrossel “Em Destaque”, presente na página inicial, é possível verificar que este não está implementado de forma semanticamente correta. Os slides que constituem o carrossel estão implementados como elementos div em vez de estarem organizados como lista não ordenada(<ul> <li>) (Figura 15), o que facilitaria a compreensão e a navegação por parte de utilizadores de tecnologias assistivas. Os controlos do carrossel (setas de navegação) estão também estruturados como elementos div em vez de botões. O carrossel reproduz automaticamente os slides e não disponibiliza controlos para iniciar ou parar essa reprodução.
  Recomendamos que optem pela implementação de um carrossel que seja exclusivamente controlado pelo utilizador, desativando a reprodução automática. Em alternativa, manter a reprodução automática mas acrescentar um controlo visível e acessível que permita pausar e retomar o avanço dos slides.

  

  Figura 1 - Carrossel "Em Destaque", na página inicial, estruturado através de elementos div.

  Recomendamos que seja revista a estrutura semântica destes componentes para garantir o correto funcionamento dos mesmos. Para mais informações é possível consultar os artigos Carousel Structure e Carousel (Slide Show or Image Rotator) Pattern do W3C.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: O foco não está limitado ao menu

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 9.2

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

  Manter o foco do teclado dentro da caixa de diálogo garante que os utilizadores possam interagir com o seu conteúdo sem distrações de outros elementos na página. Este controlo do foco facilita a navegação, ajudando os utilizadores a compreenderem a sua posição na interface.

  Quando o menu está aberto em resoluções de tablet e mobile, é possível continuar a percorrer com o leitor de ecrã o conteúdo do website que se encontra abaixo do menu (Figura 1).

  Recomendamos que ao utilizar o teclado ou leitor de ecrã, o foco seja limitado apenas para o conteúdo da modal, neste caso, o menu. Enquanto o menu estiver aberto, a navegação por outras opções do website não deve ser possível.

  

  Figura 1 - Com a modal de menu aberta em resolução mobile, o leitor de ecrã continua a aceder ao restante conteúdo do site.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: O botão fechar não está acessível pelo leitor de ecrã

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 9.3

  A caixa de diálogo tem de ter um mecanismo que permita sair ou fechar a caixa, quer através de teclado quer através de um dispositivo apontador
  – ver requisito 9.3 na lista 10 aspetos

  As modais devem apresentar um botão de fechar claramente visível e acessível através do teclado. Além disso, podem permitir que os utilizadores as fechem pressionando a tecla 'Esc'. Essas opções garantem que utilizadores de teclado e leitores de ecrã consigam interagir com a modal de forma eficaz.

  Verificámos que, na janela modal associada ao botão de pesquisa, não é possível aceder ao botão "Fechar” através do leitor de ecrã. Este problema acontece quer na versão desktop quer na versão mobile (Figura 1 e Figura 2).

  Recomendamos rever o botão de "Fechar” desta modal e , adicionalmente, implementar um mecanismo para fechar a modal através da tecla de atalho “ESC”.

  

  Figura 1 - Não é possível aceder ao botão de fechar através do leitor de ecrã. Teste em desktop.

  

  Figura 2 - O botão de fechar não está acessível através do leitor de ecrã na versão mobile do site.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: Não existe um resumo do propósito do site na homepage

  etiqueta: chk conteúdoetiqueta: NOKetiqueta: R 1.1

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

  O propósito do website difere da missão ou do objetivo da entidade. 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.

  Não existe qualquer resumo do propósito na Homepage da Livraria Online do Teatro Nacional D.Maria II, pelo que deve ser adicionado (Figura 1).

  Como referência de uma boa prática, é possível verificar no website acessibilidade.gov que o seu propósito está escrito no topo da página (Figura 2).

  

  Figura 1 - Homepage não mostra um breve resumo do propósito do website.

  

  Figura 2 - Página inicial do site acessibilidade.gov que mostra o propósito do website no topo da página.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: Não existe um glossário para termos complexos

  etiqueta: chk conteúdoetiqueta: NOKetiqueta: R 1.2

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

  Em sites com termos técnicos ou complexos, que sejam difíceis de compreender, deve existir uma página de glossário com as definições dessas palavras. O glossário deve apresentar a definição dos termos e conceitos de forma clara e breve, para que seja facilmente compreensível pelos utilizadores.

  Não foi encontrado um glossário no website da Livraria Online do Teatro Nacional D.Maria II, apesar de existirem termos técnicos em várias páginas.

  Recomenda-se a criação de uma página com um glossário que agregue os termos complexos e a sua definição. Pode ser utilizado como referência o glossário do site da Acessibilidade: https://www.acessibilidade.gov.pt/glossario/.

  

  Figura 1 - Página Privacidade que contém termos complexos como "pessoa colectiva" ou "consentimento informado".

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

Lista de evidências recolhidas:

• evidência: Há datas de atualização com tamanho igual ao conteúdo de texto

  etiqueta: chk conteúdoetiqueta: melhoriaetiqueta: R 1.3

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

  Deve-se garantir que a informação secundária é legível e diferente do restante texto envolvente, colocando um tamanho de fonte inferior 2 pontos ao corpo de texto.

  Na página Ecodramaturgia, a data de atualização está com um tamanho de fonte igual ao conteúdo do texto, de 16px (ver Figuras 1 e 2). Recomenda-se alterar para um tamanho que seja no mínimo 2pt menor que o conteúdo, e que não seja menor que 12px.

  

  Figura 1 - Página Ecodramaturgia onde o tamanho do texto da data de atualização é de 16px.

  

  Figura 2 - Página Ecodramaturgia onde o tamanho do corpo de texto é de 16px (igual ao tamanho da data de atualização).

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: Existem blocos de texto com mais de 100 caracteres por linha

  etiqueta: chk conteúdoetiqueta: NOKetiqueta: R 2.3

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

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

  Na resolução desktop da página Privacidade, há blocos de texto que ultrapassam os 100 caracteres por linha. Por exemplo, como se mostra na Figura 1, a terceira linha do texto principal — “utilizador. Esta declaração de privacidade(…)” — contém 104 caracteres.

  Recomenda-se 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) para garantir que não é ultrapassado o número máximo de caracteres por linha.

  

  Figura 1 - Análise da versão desktop da página Privacidade através da extensão do browser Character Counter. A terceira linha do texto principal contém 104 caracteres.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: O menu principal contém itens com mais de 9 subopções

  etiqueta: chk conteúdoetiqueta: NOKetiqueta: R 3.1

  Nenhum nível de navegação tem mais de 9 opções.
  – ver requisito 3.1 na lista Conteúdo

  As boas práticas recomendam que nenhum nível do menu deve ter mais do que 9 opções. A navegação deve ser equilibrada e não deve exigir muito esforço cognitivo por parte dos utilizadores, que normalmente retêm entre 5 a 9 opções na memória de curto prazo.

  Na opção do menu principal “Outras Edições” existem 22 subopções, o que significa que está acima do número de opções recomendado (Figura 1).

  Deve ser feita uma revisão da arquitetura de informação do menu de forma a garantir que não ultrapasse 9 opções em cada nível do mesmo.

  

  Figura 1 - Opção do menu principal "Outras Edições" tem 22 subopções.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: Não existe um índice no topo de uma página longa

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

  Para facilitar a navegação em páginas longas, com várias secções de conteúdos, deve existir um índice no topo da página. Esse índice deve conter hiperligações para as várias seções que existem.

  Nas páginas consideradas longas, como as páginas Declaração de Acessibilidade e Usabilidade e Privacidade (ver Figura 1), não existem um índice com hiperligações para cada secção interna dessa página.

  Recomendamos adicionar um índice com hiperligações para cada secção interna.

  

  Figura 1 - Página Privacidade, uma página longa, sem índice no topo da página.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: Há elementos interativos com área clicável que não cumprem a dimensão mínima exigida (44px de altura e largura)

  etiqueta: chk conteúdoetiqueta: NOKetiqueta: R 5.2

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

  Para garantir que os utilizadores interagem devidamente com um elemento interativo (botões, imagens-link...), a área clicável desse elemento deve ser, no mínimo, 44px de largura e 44px de altura.

  No breadcrumb presente nas páginas de interior, a imagem-link representativa da página inicial tem uma área clicável com 27px de altura e 28px de largura, não cumprindo as dimensões mínimas necessárias. (Figura 1)

  Devem garantir que os elementos interativos têm uma altura e largura igual ou superior a 44px de área clicável, mesmo que o ícone/imagem tenha um tamanho inferior.

  

  Figura 1 - Verificação das medidas do ícone de página inicial no breadcrumb da página Textos de Teatro através da extensão Web Developer. A área clicável desta imagem-link é de 27px de altura por 28px de largura.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: Existem formulários longos sem divisão por passos

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

  Em formulários longos, com mais de 2 ecrãs de altura, deve-se garantir que a informação é pedida ao utilizador de forma faseada, dividindo os passos em várias páginas ou secções. No caso de formulários curtos, não é necessário fazer esta divisão.

  Nas páginas Registo de Conta de Cliente e Pedidos de Devolução, existem formulários longos onde os campos são todos mostrados numa única página.

  Recomendamos a estrutura dos formulários mais longos, de forma a segmentar os passos em várias páginas ou secções.

  

  Figura 1 - Página Registo de Conta Cliente.

  

  Figura 2 - Página Pedidos de Devolução.

etiqueta: N/A

Lista de evidências recolhidas:

• evidência: R 1.3 - Transação

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

  Os formulários com mais de uma página têm a sequência de passos ilustrada.
  – ver requisito 1.3 na lista Transação

  Não foram encontrados formulários com mais de uma página dentro do domínio do site.

etiqueta: NOK

Lista de evidências recolhidas:

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

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

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

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

  No caso do formulário da página de Registo de Conta Cliente, a largura dos campos não reflete o tamanho previsível dos dados. É possível observar que os campos do NIF, código postal e cidade tem uma largura demasiado extensa para a informação a inserir, induzindo que se pode escrever mais (Figura 1).

  Recomendamos rever todos os campos dos formulários do site para garantir que a sua largura corresponde ao tipo de informação a preencher por forma a evitar confusões sobre o conteúdo esperado.

  

  Figura 1 - Página Registo de Conta Cliente onde todos os campos têm a mesma largura independente do tamanho dos dados.

etiqueta: N/A

Lista de evidências recolhidas:

• evidência: R 2.2 - Transação

  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

  Analisámos os formulários do site e constatamos que não têm campos inativos.

  

  Figura 1 - Página Pedidos de Devolução.

etiqueta: N/A

Lista de evidências recolhidas:

• evidência: R 4.2 - Transaçã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

  Não existem formulários com ações destrutivas dentro do domínio do site.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: Não são devolvidas mensagens de erro junto a cada campo do formulário

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

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

  No formulário da página Registo de Conta Cliente, as mensagens de erro são apresentadas de forma genérica, uma de cada vez e apenas depois de o formulário ser submetido. Para que o formulário seja acessível, cada campo deve exibir a sua própria mensagem de erro, a indicar claramente o problema detetado, de forma visível e compatível com leitores de ecrã. Ao apresentar uma única mensagem, o utilizador pode não perceber todos os problemas de forma clara e eficiente.

  Além disso, verificou-se que é possível inserir números e símbolos em campos destinados a texto, como “Nome” e “Apelido”, bem como introduzir letras em campos que deveriam aceitar apenas números, como “NIF” e “Telefone” (Figura 1)

  Recomendamos a revisão dos formulários do site para garantir que devolvem mensagens de erro junto aos campos com dados incorretos ou não preenchidos e que essas mensagens indiquem também o formato correto de preenchimento dos dados - por exemplo, “Introduza apenas letras” ou “Introduza 9 dígitos”.

  

  Figura 1 - Formulário Registo de Conta Cliente antes da sua submissão através do botão "Continuar".

  

  Figura 2 - Página Registo de Conta Cliente após a submissão do formulário. Embora existam vários erros de preenchimento, apenas é exibida uma mensagem de erro — “Inclua um ‘@’ no endereço de email. Falta um ‘@’ em ‘$#987510=’” —associada ao campo de email.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: Falta de mensagens de erro específicas por campo

  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

  No formulário da página Registo de Conta Cliente não são apresentadas mensagens de erro específicas junto a cada campo com erros. Para garantir uma maior clareza, cada campo deve exibir a sua própria mensagem de erro, descrevendo claramente o problema detetado, de forma visível e compatível com leitores de ecrã.

  Como mostrado na Figura 1, mesmo existindo vários campos com dados incorretos — como “Nome” e “Apelido” — apenas é mostrada uma mensagem de erro, associada ao campo “E-mail”. Além disso, “Nome” e “Apelido” permitem a introdução de números e símbolos, o que não é adequado para estes campos.

  Recomenda-se a revisão dos formulários do site para que todos os campos com dados incorretos ou não preenchidos apresentem mensagens de erro claras e localizadas junto ao respetivo campo. Essas mensagens devem também indicar o formato correto de preenchimento. Por exemplo, no campo “Código Postal” pode ser apresentada a instrução: “Insira um código postal válido, utilizando o formato 0000-000.”

  

  Figura 1 - Página Registo de Conta Cliente depois da submissão do formulário.