Relatório Avaliação de Candidatura
Agência de Gestão da Tesouraria e da Dívida Pública IGCP

Introdução

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

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

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

Níveis de conformidade das avaliações manuais
ChecklistConformidade alcançadaResultado
10 aspetos60.0% (15/25)etiqueta: Não passa
Conteúdo64.7% (11/17)etiqueta: Não passa
Transação66.7% (6/9)etiqueta: Não passa

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

Avaliação automática

etiqueta: NOK

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

Lista de evidências recolhidas:

Avaliação manual

etiqueta: NOK

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

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

Checklist 10 aspetos

etiqueta: NOK

Nível de conformidade:

  • Checklist 10 aspetos: 60.0% (15/25)
    • Requisitos avaliados: 27 (2 N/A excluídos, 25 aplicáveis)
    • Requisitos OK: 15
    • Requisitos NOK: 10
    • Requisitos N/A: 2

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

etiqueta: NOK

Lista de evidências recolhidas:

  • evidência: issue #5 Uso inapropriado de atributos no menu

    etiqueta: chk 10 webetiqueta: NOKetiqueta: R 1.2

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

    Evidencias
    O atributo aria-haspopup é utilizado 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 devem recorrer a este atributo:

    Recomendações

    • Remover esse atributo do menu, uma vez que se trata de uma menu de navegação e não de aplicação.
    • A informação de que o menu contém subopções deve ser feita pelo aria-expanded.
  • evidência: issue #4 Não é possível navegar com o leitor de ecrã nas opções do menu

    etiqueta: chk 10 webetiqueta: NOKetiqueta: R 1.2

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

    Evidencias:
    Quando navegamos pelo menu principal utilizando leitor de ecrã Voice Over, verifica-se que as opções do menu não são exibidas quando utilizamos o comando VO + espaço no Safari:


    URL a verificar
    https://www.igcp.pt/pt - menu principal

    Recomendações:

    • É necessário assegurar a compatibilidade com o leitor de ecrã Voice Over no Safari quando utiliza o comando VO+Espaço. O JavaScript deve controlar a abertura e o fecho das opções do menu através de um evento onclick.
    • O problema identificado não está relacionado com a estrutura semântica apresentada no DOM. Por isso é necessário verificar se existe algum conflito entre os eventos associados aos botões do menu. Por exemplo, é possível observar que o evento onclick está sendo aplicado no botão e na tag header.

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

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

Lista de evidências recolhidas:

  • evidência: issue #6 O h1 não está atrelado ao logótipo na página inicial

    etiqueta: chk 10 webetiqueta: R 2.1etiqueta: melhoria

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

    Evidencias
    O logotipo da página inicial não está sendo atribuído como título h1 pelo que deve ser corrigido:

    Recomendações
    O elemento atualmente definido como h1 “Bem-vindo ao IGCP, E.P.E.” deve ser estruturado como um parágrafo p para que o h1 seja atribuído ao logotipo. Além disso, o texto alternativo do logotipo deve ser alt="Agência de Gestão da Tesouraria e da Dívida Pública IGCP".

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

etiqueta: NOK

Lista de evidências recolhidas:

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

etiqueta: NOK

Lista de evidências recolhidas:

  • evidência: issue #11 Existem tabelas com cabeçalhos em branco

    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

    Evidencias:
    Verifica-se a existência de tabelas com o th vazio:


    Recomendações:
    Remover os th que são vazios.

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

etiqueta: NOK

Lista de evidências recolhidas:

  • evidência: issue #12 Existem tabelas que não possuem o caption

    etiqueta: chk 10 webetiqueta: NOKetiqueta: R 3.2

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

    Evidencias:
    Verifica-se, no website, a existência de tabelas sem títulos:

    Recomendações:

    • Alterar a estrutura do conteúdo para que, em vez de ser apresentada como uma tabela, passe a ser organizada como uma lista ul li.

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

etiqueta: NOK

Lista de evidências recolhidas:

  • evidência: issue #14 Não é possível distinguir quais campos são obrigatórios visualmente (incluir issue)

    etiqueta: chk 10 webetiqueta: NOKetiqueta: R 4.2

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

    Evidencias:
    No formulário de contactos existem campos de preenchimento obrigatórios e opcionais. Para as tecnologias de apoio, é possível distinguir quais campos são obrigatórios. Contudo, essa distinção não é perceptível visualmente.

    Embora seja apresentada uma mensagem de erro assim que o foco é retirado do campo, esta abordagem não informa de forma imediata que o campo é obrigatório enquanto o utilizador o está a preencher. O utilizador apenas descobre essa obrigatoriedade depois de sair do campo, sendo forçado a regressar para continuar o preenchimento, ou pode nem chegar a percorrer o campo obrigatório, o que não é apropriado:

    O campo “Tema” está identificado com o asterisco (*). Contudo, os restantes campos obrigatórios não apresentam qualquer indicação visual. Não é possível distinguir que o campo "Número de conta aforro" é opcional

    URLs a verificar

    Recomendações:

    • Deve ser possível distinguir claramente quais os campos obrigatórios e quais os opcionais. Para isso, é necessário indicar visualmente que o campo é obrigatório, podendo fazê‑lo através do asterisco (*) ou adicionando o texto “obrigatório” junto ao nome da respetiva label.
    • Caso optem em utilizar o asterisco, devem apresentar no topo do formulário uma descrição do seu significado. Recomendamos efetuarem a correção da issue xx relativa ao significado dos campos.

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

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

Lista de evidências recolhidas:

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

etiqueta: NOK

Lista de evidências recolhidas:

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

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

Lista de evidências recolhidas:

  • evidência: issue #18 Uso de ferramentas externas para apresentar gráficos e relatórios

    etiqueta: chk 10 webetiqueta: R 5.2etiqueta: melhoria

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

    Evidências:

    Na página Taxas de Câmbio está sendo utilizado uma ferramenta externa, o PowerBI, para apresentar as transações efetuadas pelo IGCP:


    O critério está a passar porque embora estejam utilizando essa ferramenta é possível encontrar uma versão alternativa, seja um ficheiro ou uma página que apresente a informação.

    Embora o PowerBI permite visualizar a informação em tabelas, existe uma incompatibilidade entre sistema Mac vs. Windows com a tecnologia Power BI, podendo afetar as tecnologias de apoio de diferentes formas.

    Adicionalmente, importa salientar que a utilização do PowerBI evidencia outros problemas críticos de acessibilidade, nomeadamente a apresentação de informação em tabelas sem a devida utilização de caption, bem como a ausência de um cabeçalho de nível H1 na página, entre outros aspetos relevantes.

    Recomendações:

    • Devem evitar a utilização desta ferramenta, uma vez que garantir a acessibilidade da informação implica um esforço significativo e a posse de conhecimentos especializados na plataforma, de forma a assegurar que estes e outros pontos críticos são devidamente identificados e corrigidos.
    • Ao invés de disponibilizar ficheiros no formato PDF, excel a informação pode ser transmitida em HTML através de uma página do website.
  • evidência: issue #17 A descrição detalhada do organograma está em outra secção

    etiqueta: chk 10 webetiqueta: R 5.2etiqueta: melhoria

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

    Evidências:
    Na página Organização, o organograma está disponível dentro do acordeão "Organograma". No entanto, a explicação sobre o funcionamento da estrutura organizacional encontra-se numa secção distinta, no acordeão "Como funciona na prática a organização IGCP". Esta separação entre a imagem do organograma e a sua explicação pode gerar dúvidas sobre a relação entre ambos os conteúdos:

    Imagem e descrição em texto separada em dois acordeões

    Recomendações:
    A imagem e a sua respetiva descrição em texto devem ser apresentados no mesmo acordeão.
    Outra alternativa, poderá ser adicionada um link âncora junto à imagem, com a indicação “Consultar descrição do organograma”, que ao ser clicada direcionaria o utilizador para o acordeão “Como funciona na prática a organização do IGCP?”:

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

etiqueta: NOK

Lista de evidências recolhidas:

  • evidência: issue #19 As imagens-link possuem um texto alternativo incorreto

    etiqueta: chk 10 webetiqueta: NOKetiqueta: R 5.3

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

    Evidências:
    Verifica-se que alterações foram efetuadas, no entanto, ainda é necessário ajustes para garantir o correto entendimento do texto alternativo. Nos logótipos do IGCP, o texto alternativo foi alterado para "Agência de Gestão da Tesouraria e da Dívida Pública IGCP" e está correto. Contudo, ainda falta a informação que ao clicar o utilizador será direcionado para a página inicial do website:

    Logotipo apresentado no topo da página

    Logotipo apresentado no rodapé da página


    Outro exemplo acontece com o nome acessível dos links de idioma da página. Quando navegamos com o leitor de ecrã é anunciado como "PT" e "EN". Essa descrição pode não ser clara para todos os utilizadores:

    Recomendações:

    • Incluir no texto alternativo a informação que o utilizador será direcionado para a página inicial. Por exemplo: alt="Agência de Gestão da Tesouraria e da Dívida Pública IGCP: Ir para página inicial".
    • Outra alternativa que pode ser feita seria indicar essa informação pelo title (title="Ir para página inicial").
    • Nos links de idiomas, idealmente é que o texto visível apresente o nome completo do idioma. Contudo, caso optem em manter a abreviação do idioma outra possibilidade seria nomear através do aria-label a descrição completa do idioma, como por exemplo: aria-label="PT: português" e aria-label="EN: english".
      Atenção: os botões devem estar corretamente identificados com o seu respectivo idioma programaticamente. Para isso, utilizem o atributo lang.
      Observação: quando existem dois idiomas, é necessário apresentar o link do idioma atualmente ativo? Em alternativa, podem analisar a possibilidade de apresentar apenas o botão correspondente ao idioma disponível para mudança.

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

etiqueta: N/A

Lista de evidências recolhidas:

  • evidência: issue #22 Não foi identificado vídeos/players no website

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

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

    Evidências:
    Não foi encontrado na amostra exemplos de vídeos ou players apresentados no website. Por esse motivo consideramos o critério como não aplicável.

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

etiqueta: N/A

Lista de evidências recolhidas:

  • evidência: issue #23 Não foi identificado vídeos/players no website

    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

    Evidências:
    Não foi encontrado na amostra exemplos de vídeos ou players apresentados no website. Por esse motivo consideramos o critério como não aplicável.

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

etiqueta: NOK

Lista de evidências recolhidas:

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

etiqueta: NOK

Lista de evidências recolhidas:

  • evidência: issue #31 O foco não está limitado ao conteúdo da modal

    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

    Evidências:
    Quando navegamos com o leitor de ecrã com a modal de pesquisa aberta, continua a sendo possível aceder e consultar conteúdos da página que deveriam estar inacessíveis:

    URLs a verificar

    Recomendações

    • O foco deve ser limitado apenas para o conteúdo da modal, nesse caso a pesquisa. Enquanto a pesquisa estiver aberta, a navegação por outras opções do website não deve ser possível.

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

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

Lista de evidências recolhidas:

  • evidência: issue #32 O botão fechar está acessível, mas informa o seu estado sem a necessidade

    etiqueta: chk 10 webetiqueta: R 9.3etiqueta: melhoria

    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

    Evidências:
    É possível fechar a modal através do botão “Fechar” ou da tecla ESC. No entanto, quando a modal é fechada com o leitor de ecrã, é anunciado o estado “fechado/colapsado” do botão, o que não corresponde ao comportamento esperado pois é um botão de ação (fechar) não de expansão:

    Recomendações:

    • Remover o atributo aria-expanded do botão fechar.
    • O fechamento da modal deve ser feito via script através de um evento específico de fechar.

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

etiqueta: NOK

Lista de evidências recolhidas:

  • evidência: issue #34 Não é possível extrair o texto de ficheiros PDF para outro processador de texto

    etiqueta: chk 10 webetiqueta: NOKetiqueta: R 10.1

    Nos ficheiros PDF é possível, no mínimo, extrair o conteúdo textual para formato TXT.
    ver requisito 10.1 na lista 10 aspetos

    Evidências:
    Na página Planos de Atividades e Orçamento, foi identifica na análise anterior alguns ficheiros PDF que contêm imagens e seu conteúdo não é extraído para um processador de texto, como o Word.

    Contudo, não foi possível avaliar os ficheiros identificados anteriormente pois o link é inválido. Está sendo apresentado a mensagem de que a página não foi encontrada. Por esse motivo, o critério continua a não cumprir:

    Evidência do não cumprimento do critério enviado anteriormente

    Recomendações:

    • Rever todos os ficheiros PDF para assegurar que as informações em texto possam ser corretamente extraídas para um documento de texto, como o Word. As informações apresentadas em imagens, devem ter a sua descrição alternativa em texto.
    • Verificar todas as páginas do website que estão apresentando a mensagem de erro. Devem garantir que seja possível aceder aos documentos.

Checklist Conteúdo

etiqueta: NOK

Nível de conformidade:

  • Checklist Conteúdo: 64.7% (11/17)
    • Requisitos avaliados: 17 (17 aplicáveis)
    • Requisitos OK: 11
    • Requisitos NOK: 6

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

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

Lista de evidências recolhidas:

  • evidência: issue #35 O propósito do site não é explícito

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

    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:

    A descrição do propósito “A Agência de Gestão de Tesouraria e da Dívida Pública – IGCP, E.P.E. é a entidade pública a quem compete gerir a tesouraria, o financiamento e a dívida pública direta do Estado Português.” pode não descrever apropriadamente quais as tarefas ou informações que é possível encontrar no website:

    Recomendações:

    • A descrição do propósito deve ser alterada para representar mais fielmente a finalidade do site e a informação que contém, tal como se verifica no exemplo do site do selo:

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

etiqueta: NOK

Lista de evidências recolhidas:

  • evidência: issue #38 Existem conteúdos sem data de atualização

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

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

    Evidências:
    O website não apresenta data de atualização do conteúdo. Por exemplo, na página Glossário não possui data de atualização:

    URLs a verificar

    • Todas as páginas internas do website.

    Recomendações:

    • Para garantir que o utilizador está informado sobre a atualidade dos conteúdos, devem ser adicionadas as datas de atualização a todas as páginas e/ou blocos de conteúdo do site.

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

etiqueta: NOK

Lista de evidências recolhidas:

  • evidência: issue #39 O website apresenta o responsável pelo conteúdo e disponibiliza diferentes canais de contacto

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

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

    Evidências:
    O critério está a cumprir: é possível identificar o responsável pelo conteúdo do website no rodapé. O website apresenta no mínimo, duas formas de contacto, por telefone ou digital (email ou preenchimento de formulário):

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

etiqueta: NOK

Lista de evidências recolhidas:

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

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

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

    Evidências:
    Nas páginas Bilhetes do Tesouro (BT) e Missão, Visão e Valores existem blocos de texto com tamanho acima do recomendado. Este problema ocorre em todo o website, uma vez que não foi definido um tamanho máximo para as caixas de texto (max-width). Como resultado, o tamanho do bloco de texto ajusta-se conforme o tamanho do monitor utilizado. Ou seja, em monitores maiores, o tamanho do bloco de texto acaba por ser consideravelmente maior.

    Bloco de texto com 157 caracteres na página Bilhetes do Tesouro (BT)

    Bloco de texto com 157 caracteres na página Missão, Visão e Valores

    URLs a verificar

    • Todas as páginas do website.

    Recomendações:

    • Definir uma largura máxima para as caixas de texto (max-width, em CSS), com unidades relativas ao tamanho de fonte (unidades px, em ou rem) para garantir que não é ultrapassado o número máximo de caracteres por linha.

Requisito 3.1 - Nenhum nível de navegação tem mais de 9 opções

etiqueta: NOK

Lista de evidências recolhidas:

  • evidência: issue #44 As subopções do menu ultrapassam 9 opções

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

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

    Evidências:
    No menu, existem 10 subopções em “Investidores” e 13 subopções em “Aforristas” o que significa que está acima do número de opções recomendado:

    URLs a verificar

    Recomendações

    • Rever a arquitetura de informação do menu de forma a garantir que não ultrapasse 9 opções em cada nível do mesmo.

Requisito 3.2 - A navegação principal está sempre visível e sempre no mesmo local

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

Lista de evidências recolhidas:

  • evidência: issue #45 O ícone do menu não tem um texto descritivo

    etiqueta: R 3.2etiqueta: chk conteúdoetiqueta: melhoria

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

    Evidências:
    O menu de mobile/tablet é apresentado apeanas como um ícone de “Menu Hambúrguer" o que pode não ser claro para todas as pessoas:

    Recomendações:

    • Idealmente o menu compacto deve ter uma label visível que identifique a sua função.

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

etiqueta: NOK

Lista de evidências recolhidas:

  • evidência: issue #46 As hiperligações não se diferenciam do texto envolvente

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

    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:
    No rodapé do website, o link “Formulário de contacto” está apresentado em negrito. No entanto, os textos que estão próximos também estão em negrito, não sendo possível distingui-lo como um link.

    Adicionalmente, o texto “IGCP com marcação prévia – agende aqui” surge totalmente em negrito, mas apenas o texto “agende aqui” corresponde ao link. Esta estrutura dificulta a perceção de qual parte do texto é interativa:

    Recomendações:

    • Utilizarem a mesma sinalética que está sendo apresentado nos links do website, o sublinhado.

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

etiqueta: NOK

Lista de evidências recolhidas:

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

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

Lista de evidências recolhidas:

  • evidência: issue #51 Não é perceptível a área clicável dos cards

    etiqueta: R 5.4etiqueta: chk conteúdoetiqueta: melhoria

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

    Evidências:
    O critério está a ser cumprido, mas existem melhorias a considerar: os elementos interativos aparentam ser clicáveis. Contudo, os cards apresentados em algumas páginas do website não possuem qualquer contorno. Para pessoas que utilizam recursos de ampliação e têm visão parcial, pode não ser totalmente percetível quais os elementos que compõem o cartão, nem distinguir claramente a respetiva área clicável:

    No hover não é apresentado mudanças para além das setas que já estão abaixo do conteúdo

    Image

    Contorno em foco apenas no título

    URLs a verificar

    Recomendações:

    • Devem delimitar toda a área do cartão, isso pode ser feito quando o cartão está em foco com o rato e teclado.

Checklist Transação

etiqueta: NOK

Nível de conformidade:

  • Checklist Transação: 66.7% (6/9)
    • Requisitos avaliados: 13 (4 N/A excluídos, 9 aplicáveis)
    • Requisitos OK: 6
    • Requisitos NOK: 3
    • Requisitos N/A: 4

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

etiqueta: N/A

Lista de evidências recolhidas:

  • evidência: issue #54 Os formulários apresentados no website não são maiores do que 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

    Evidências:
    Não existem formulários longos com maiores do que 2 ecrãs. Por esse motivo consideramos o critério como não aplicável.

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

etiqueta: N/A

Lista de evidências recolhidas:

  • evidência: issue #55 Não foi encontrado formulários com mais de uma página

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

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

    Evidências:
    Não foi encontrado formulários com mais de uma página. Por esse motivo considerado o critério como não aplicável.

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

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

Lista de evidências recolhidas:

  • evidência: issue #56 O tamanho dos campos refletem o tamanho previsível dos dados, mas não existe restrição do tipo de caractere

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

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

    Evidências:
    O critério está a cumprir, mas é possível efetuar melhorias: embora os campos tenham tamanho previsto do dado a preencher, verifica-se que eles não possuem restrição quanto ao tipo de caractere inserido. Por exemplo, é possível preencher o campo de contacto telefonico com textos:

    Recomendações:

    • Limitar o tipo de caracteres que é possível inserir, consoante o tipo de campo.

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

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

Lista de evidências recolhidas:

  • evidência: issue #58 Existem campos do formulário cuja legenda não é clara

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

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

    Evidências:
    O critério está a ser cumprido, mas é possível efetuar melhorias. Na página de notícias, os campos relativos à data apresentam as etiquetas “De” e “Para”. Embora estes campos permitam inserir um intervalo temporal, as etiquetas podem não ser suficientemente claras para todos os utilizadores:

    Image

    URLs a verificar

    Recomendações:

    • A etiqueta do campo deve ser alterada para deixar mais claro o que deve ser feito. Caso optem em manter a etiqueta, podem inserir uma instrução que indique claramente o tipo de informação a ser selecionado (data início e data fim).

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

etiqueta: NOK

Lista de evidências recolhidas:

  • evidência: issue #59 Não há informação clara sobre o que é o asterisco nos campos de preenchimento obrigatório

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

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

    Evidências:
    No formulário de contactos não está sendo apresentado a descrição do significado do asterísco (*):

    URLs a verificar
    https://www.igcp.pt/pt/contactos

    Recomendações:

    • Substituir o asterisco por um texto “Obrigatório” em todos os campos obrigatórios ou incluir o significado do asterisco no início do formulário.

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

etiqueta: N/A

Lista de evidências recolhidas:

  • evidência: issue #60 O website não apresenta transações longas

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

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

    Evidências:
    Os formulários do website não apresentam transações longas e não requerem tempo de espera. Por esse motivo, consideramos o critério como não aplicável.

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

etiqueta: NOK

Lista de evidências recolhidas:

  • evidência: issue #61 A mensagem de confirmação não está clara

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

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

    Evidências:
    A mensagem "Nova submissão adicionada a Contactos." pode não ser clara para todos os utilizadores pois não informa explicitamente que o formulário foi enviado com sucesso:


    Para além disso, verifica que o foco do leitor de ecrã não é posicionado na mensagem. Isso faz com que ele seja direcionado para o topo da página sendo necessário o utilizador navegar pela página até encontrar a mensagem.

    URL a verificar

    Recomendações:

    • A mensagem de sucesso deve ser mais explícita para o utilizador.
    • O foco do leitor de ecrã deve ser posicionado na mensagem de sucesso.

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

etiqueta: N/A

Lista de evidências recolhidas:

  • evidência: issue #63 Não existem ações consideradas destrutivas no website

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

    As ações destrutivas nunca devem ser permanentes, deve ser sempre possível desfazer a operação.
    ver requisito 4.2 na lista Transação

    Evidências:
    Não existem formulários que permitam realizar ações destrutivas no website. Por esse motivo consideramos o critério como não aplicável.

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

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

Lista de evidências recolhidas:

  • evidência: issue #64 As mensagens de erro estão sendo estruturadas de forma inapropriada

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

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

    Evidências:
    O critério está a cumprir, mas podem ser feito melhorias: as mensagens de erro são apresentadas junto ao campo. Contudo, verifica que elas estão sendo estruturadas como label e incorretamente associadas através do aria-labelledby:

    URLs a verificar
    https://www.igcp.pt/pt/contactos

    Recomendação

    • A mensagem de erro deve ser estruturada como uma span ou div.
    • A associação da mensagem de erro com o seu respetivo campo deve ser feita pelo aria-describedby.

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

etiqueta: NOK

Lista de evidências recolhidas:

  • evidência: issue #65 Mensagens de erro no idioma diferente do website e não ajudam a corrigir o problema

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

    Evidências:
    Existem mensagens de erro que para além de estarem num outro idioma, não ajudam a corrigir o problema de preenchimento. Por exemplo, no campo email a mensagem está em inglês e não pistas para o correto preenchimento do campo:

    URLs a verificar:
    https://www.igcp.pt/pt/contactos

    Recomendações:

    • A mensagem de erro deve ser no mesmo idioma da página.
    • As mensagens de erro devem informar pistas para auxiliar no seu correto preenchimento.
    • Para mais informações partilhamos um exemplo da mensagem de erro para um campo de email: https://www.w3.org/WAI/tutorials/forms/validation/#validating-common-input
    • Essa validação pode ser feita no campo de telefone, email, documentos, etc...

Significado das etiquetas utilizadas