Relatório Avaliação da Candidatura da APPACDM Viseu

Introdução

O website https://appacdmviseu.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 aspetos12.0% (3/25)etiqueta: Não passa
Conteúdo17.6% (3/17)etiqueta: Não passa
Transação22.2% (2/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: 12.0% (3/25)
    • Requisitos avaliados: 27 (2 N/A excluídos, 25 aplicáveis)
    • Requisitos OK: 3
    • Requisitos NOK: 22
    • Requisitos N/A: 2

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #60 Está sendo utilizado atributos inapropriados no menu

    etiqueta: NOKetiqueta: chk 10 webetiqueta: R 1.1

    O menu principal está corretamente estruturado como uma lista, utilizando as tags HTML ul e li. No entanto, estão a ser aplicados os atributos role="menu" e role="menuitem", que alteram a semântica nativa de lista e fazem com que as tecnologias de apoio interpretem o componente como um menu de aplicação:

    Image

    URL a verificar

    Sugestão de correção

    • Remover os atributos role="menu" e role="menuitem" do menu principal. Essa alteração deve ser feita no menu desktop e mobile.

  • issue #59 As opções do rodapé não estão estruturados como lista

    etiqueta: NOKetiqueta: chk 10 webetiqueta: R 1.1

    Quando utilizamos listas, fornecemos às tecnologias de apoio informações semânticas importantes, tais como: o número total de opções disponíveis e uma navegação mais eficiente, já que leitores de ecrã permitem saltar diretamente entre itens de uma lista.

    As opções apresentadas no rodapé estão a ser agrupadas através de uma tag genérica div. No entanto, quando estas opções representam um conjunto de links relacionados, é mais adequado estruturá‑las como uma lista utilizando ul e li.

    Image

    URL a verificar

    Sugestão de correção

    • As opções de redes sociais e os links da secção "Legal" devem ser estruturados como listas ul li.

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #64 Não é possível navegar para a opção seguinte do menu sem percorrer todas as subopções (melhoria)

    etiqueta: chk 10 webetiqueta: R 1.2etiqueta: melhoria

    Quando navegamos com o teclado nas opções do menu que contêm subopções, verifica‑se que o utilizador é obrigado a percorrer todas as subopções antes de conseguir regressar às opções de 1.º nível.

    Por exemplo, ao tentar selecionar a opção “Projetos” com o teclado utilizando as teclas TAB e SHIFT+TAB, torna‑se obrigatório percorrer todas as subopções de “Instituição” e “Respostas/serviços” antes de conseguir avançar, o que não é o ideal.

    Image

    Necessário percorrer todas as subopções com o teclado

    URL a verificar

    Sugestão de correção

    • O sub-menu não deverá abrir automaticamente quando tem o foco da tecla TAB, para não tornar obrigatório a sua leitura antes de ir para o próximo item.
    • Recomendamos efetuarem também as correções propostas na issue xx.

  • issue #63 Não é possível navegar com os leitores de ecrã nas subopções do menu

    etiqueta: NOKetiqueta: chk 10 webetiqueta: R 1.2

    Quando utilizamos os leitores de ecrã VoiceOver e NVDA, é possível navegar por todas as opções de 1.º nível do menu principal. No entanto, verificam‑se dois problemas:

    • Não é possível identificar quais opções possuem subopções.
    • Não é possível aceder às subopções utilizando as teclas VO + Espaço (VoiceOver) ou Enter (NVDA).
    Image

    Voice Over não anuncia que a opção "Instituição" está fechada e não é possível abrir utilizando as teclas VO + espaço e o ENTER

    URL a verificar

    Sugestão de correção

    • O sub-menu não deverá abrir automaticamente quando tem o foco da tecla TAB, para não tornar obrigatório a sua leitura antes de ir para o próximo item.
    • Utilizar o atributo aria-expanded e o JavaScript para gerenciar a abertura e fecho das subopções do menu. Recomenda-se criar um evento de clique que irá abrir ou fechar as sub-opções de acordo com a seleção feita pelo utilizador.
    • Utilizar o atributo ARIA “aria-current” para as tecnologias de apoio identificarem estruturalmente em qual das opções do menu é que o utilizador se encontra.
    • Devem garantir que que as opções de 1º nível do menu fiquem fechadas até que o utilizador escolha aceder às subopções com a tecla ENTER ou VO+espaço.
    • Devem garantir que as opções de 1º nível se fechem quando o foco do teclado não está numa delas.
    • Podem utilizar a tecla ESC como uma tecla adicional que permita fechar as subopções do menu.

  • issue #62 Não é possível identificar quando a opção está aberta ou fechada

    etiqueta: NOKetiqueta: chk 10 webetiqueta: R 1.2

    Quando selecionamos uma subopção no menu mobile, o leitor de ecrã não anuncia se ela está aberta ou fechada. Por exemplo, quando abrimos a opção "Instituição" o leitor de ecrã não anuncia que essa opção foi expandida:

    Image

    Da mesma forma, o leitor de ecrã não anuncia as opções que estão fechadas, como por exemplo, a opção "Respostas/Serviços":

    Image

    URL a verificar

    Sugestão de correção

    • É necessário implementar no código um evento/script que permita ao atributo aria-expanded mostrar ou esconder as subopções.

  • issue #61 As opções do menu não apresentam uma indicação visual de que contêm subopções

    etiqueta: NOKetiqueta: chk 10 webetiqueta: R 1.2

    O menu principal não diferencia visualmente as opções que possuem subopções. Por exemplo, “Notícias” e “Projetos” apresentam o mesmo estilo, o que impede o utilizador de perceber que uma delas contém submenus:

    Image

    Todas as opções do menu são atualmente apresentadas com o mesmo estilo visual

    Image

    A opção “Projetos” contém subopções, mas essa informação só se torna visível quando o utilizador passa o cursor sobre o item ou navega através do teclado

    URL a verificar

    Sugestão de correção

    • As opções do menu que contêm subopções devem apresentar uma indicação visual que permita distingui-las. Por exemplo, pode ser utilizada a sinalética ▾ junto ao nome da opção.
    • Recomendamos que sejam efetuadas também as correções propostas na issue xx, de forma a garantir o correto funcionamento e apresentação do menu.

Requisito 1.3 - As imagens-link, caso existam no menu, devem ter o correspondente equivalente alternativo em texto

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

Lista de evidências recolhidas:

  • issue #65 Preenchimento do alt e aria-label com emoji (melhoria)

    etiqueta: R 1.3etiqueta: chk 10 webetiqueta: melhoria

    O nome acessível do campo de pesquisa está a ser definido simultaneamente através do atributo aria-label e do atributo alt da imagem. Para além de o aria-label estar a ser utilizado sem necessidade — uma vez que o texto do link já cumpre essa função — tanto o aria-label como o alt estão preenchidos apenas com o emoji 🔍.

    Esta abordagem pode gerar inconsistências na leitura entre diferentes tecnologias de apoio e navegadores, comprometendo a experiência de utilizadores que dependem de leitores de ecrã.

    Image

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

etiqueta: NOK

Lista de evidências recolhidas:

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

etiqueta: NOK

Lista de evidências recolhidas:

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

etiqueta: N/A

Lista de evidências recolhidas:

  • issue #31 Não foram encontradas tabelas

    etiqueta: N/Aetiqueta: chk 10 webetiqueta: 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.

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

etiqueta: N/A

Lista de evidências recolhidas:

  • issue #32 Não foram encontradas tabelas

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

    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.

Requisito 4.1 - Ao clicar com o rato na etiqueta, o cursor surge no respetivo campo de edição

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #85 Existem etiquetas que referenciam ids inexistentes

    etiqueta: chk 10 webetiqueta: melhoriaetiqueta: R 4.1

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

    As etiquetas do formulário da página FAZER UMA DENÚNCIA referenciam ids que não existem na página:

    Image

    Etiqueta assunto referencia id inexistente
    Recomendamos a atribuição de um id a cada campo e a referência de cada etiqueta para o respetivo campo através do id.

    Para além do problema apresentado acima, este formulário tem inúmeros problemas de acessibilidade que a entidade deve averiguar se existe a possibilidade de serem corrigidos:

    • Os campos "Entidade a denunciar" e "Categoria" são campos personalizados que não têm enriquecimento de acessibilidade, o que faz com que seja extremamente difícil a interação dos leitores de ecrã com os mesmos.
      Recomendamos a simplificação do formulário, que deve ser constituiído preferencialmente por campos nativos;
    • As etiquetas associadas a caixas de texto aparecem depois da respetiva caixa em vez de aparecerem antes;
    • Não existe indicação legível pelas tecnologias de apoio relativamente a campos de preenchimento obrigatório.

  • issue #75 Existem caixas de verificação não envolvidos em elementos `<fieldset>`

    etiqueta: NOKetiqueta: chk 10 webetiqueta: R 4.1

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

    Os grupos de checkboxes do formulário na página SUGESTÕES, ELOGIOS E RECLAMAÇÕES não estão envolvidos em elementos <fieldset>:

    Image

    Etiqueta incorretamente aplicada ao grupo de checkboxes
    Como se pode observar na figura, as checkboxes “Sugestão”, “Elogio” e “Reclamação” estão associadas à legenda “Escolha uma opção: *”. No entanto, essa associação não existe semanticamente.
    Para que tal aconteça, os botões de rádio devem ser colocadas dentro de um elemento <fieldset>, elemento esse que deve ter como primeiro filho um elemento <legend> contendo o texto “Escolha uma opção: *”, da seguinte forma:

    <fieldset>
  <legend>Escolha uma opção: *</legend>
  <input id = " rchk1 " type = "checkbox">
  <label for = "chk11">Sugestão</label>
  <input id = "chk2" type = "checkbox">
  <label for = "chk2">Elogio</label>
  <input id = "chk3" type = "checkbox">
  <label for = "chk3">Reclamação</label>
</fieldset>

    Desta forma, ao navergarmos com o teclado pelos botões de rádio, os leitores de ecrã anunciam, para além do texto do elemento

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #73 Não é possível identificar campos obrigatórios nos ficheiros PDF

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

    Verificámos que, no formulário “PROPOSTA DE ASSOCIADO”, disponível na página ASSOCIADOS, não é possível reconhecer os campos de preenchimento obrigatório. Esta informação não é passada quer visualmente quer para os leitores de ecrã.

    Uma solução mais acessível seria disponibilizar o formulário diretamente no site, em vez de em formato PDF. Nos formulários web, os campos obrigatórios devem incluir os atributos required ou aria-required=”true” para serem identificados pelas tecnologias de apoio como obrigatórios.

    Adicionalmente, deve ser apresentada uma indicação visual clara junto ao rótulo — por exemplo, “(Campo obrigatório)” — para que todos os utilizadores consigam identificar facilmente os campos que têm obrigatoriamente de preencher.

    Image

    Figura - Formulário “PROPOSTA DE ASSOCIADO”, disponível na página ASSOCIADOS onde não é possível reconhecer os campos de preenchimento obrigatório.

  • issue #72 Não há informação clara sobre o que é o asterisco nos campos de preenchimento obrigatório

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

    Os campos obrigatórios dos formulários devem estar devidamente identificados como tal. Idealmente, devem apresentar o texto “Obrigatório” à frente da legenda do campo. Pode-se colocar um * no campo obrigatório, desde que o significado do * seja mencionado no início do formulário.

    No formulário da página Contactos não existe informação sobre o significado do asterisco nos campos.

    Recomendamos a revisão dos formulários por forma a adicionarem uma legenda no início do formulário que indique claramente o significado de . Por exemplo, “ Campos de preenchimento obrigatório”.

    Adicionalmente, no caso dos formulários das páginas Voluntariado e Candidatura Espontânea – em que, à frente dos rótulos dos campos é usado “* (obrigatório)”, o que configura uma duplicação da indicação de campo de preenchimento obrigatório.
    Recomendamos que seja usado apenas “(obrigatório)” ou “(campo obrigatório)” à frente dos rótulos dos campos, ou em alternativa o uso do * (desde que a indicação do seu significado conste no topo do formulário).

    Image

    Figura 1 - Formulário da página Contactos. Não existe informação sobre o significado do asterisco nos campos.

    Image

    Figura 2 - Formulário da página Candidatura Espontânea.

  • issue #71 Há campos obrigatórios que não estão identificados programaticamente

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

    Verificámos que no formulário da página Contactos, os campos não estão identificados programaticamente como obrigatórios.

    Recomendamos que os campos obrigatórios incluam o atributo required para serem identificados pelas tecnologias de apoio como obrigatórios.

    Image

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

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #56 Existem formulários com mensagens incompletas no topo

    etiqueta: NOKetiqueta: R 4.3etiqueta: chk 10 web

    É 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 apresentadas no topo do formulário SUGESTÕES, ELOGIOS E RECLAMAÇÕES estão incompletas e não remetem para os campos respetivos:

    Image

    Mensagens de erro no topo do formulário incompletas e sem remissão para os campos
    Neste momento não existe qualquer associação entre a mensagem no topo e os campos onde existem erros, pelo que esta mensagem não têm qualquer efeito positivo na perceção dos campos com erro de preenchimento.
    Recomendamos que as mensagens de erro apresentadas no topo de todos os formulários refiram os campos a que dizem respeito, para fornecer contexto ao utilizador que qual campo se refere cada mensagem.
    Recomendamos ainda que cada mensagem, ao ser clicada, remeta o foco para o respetivo campo (por exemplo, transformando cada mensagem num link cujo atributo href contenha o id do campo).
    Adicionalmente, solicitamos que questionem se faz sentido que a mensagem no topo seja apresentada apenas para as tecnologias de apoio.

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

    etiqueta: NOKetiqueta: R 4.3etiqueta: chk 10 web

    É 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 CONTACTOS não apresenta mensagens de erro junto aos campos:

    Image

    Campo email do formulário de contactos sem mensagem de erro associada
    As únicas mensagens de erro apresentadas ocorrem no fundo do formulário:

    Image

    Mensagem de erro no fundo do formulário

    As mensagens com a lista de erros devem ser apresentadas no topo e não no fundo dos formulários, e em formulários com número elevado de campos são de grande utilidade. Para além disso, devem ser apresentadas no mesmo idioma daquele configurado no site.
    Recomendamos que sejam apresentadas mensagens de erro junto aos campos de todos os formulários, para assim forenecerem apoio na correção dos mesmos e consequente submissão correta dos formulários.
    Adicionalmente, pode existir uma lista dos erros no topo de cada formulário que consolida os vários erros existentes, em que cada mensagem deve remeter para o respetivo campo (por exemplo, através da colocação da mensagem num link cujo href contenha o id do respetivo campo). Essa mensagem no topo deve estar no mesmo idioma do site.

  • issue #54 Existem mensagens de erro escondidas das tecnologias de apoio

    etiqueta: NOKetiqueta: R 4.3etiqueta: chk 10 web

    É 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 do formulário SUGESTÕES, ELOGIOS E RECLAMAÇÕES foram escondidas das tecnologias de apoio:

    Image

    Mensagens de erro escondidas das tecnologias de apoio através do atributo aria-hidden
    Conforme observado na figura, o span que contém a mensagem de erro associada ao não preenchimento do campo nome contém o atributo aria-hidden que oculta a mensagem de erro das tecnologias de apoio. Tal situação faz com que os utilizadores destas tecnologias fiquem impedidos de ver as mensagens de erro.
    Recomendamos a remoção do atributo aria-hidden de todas as mensagens de erro, de forma a que as mesmas estejam visíveis para todos os agentes.

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: NOK

Lista de evidências recolhidas:

  • issue #26 Imagem/gráfico não é acompanhada de uma descrição longa

    etiqueta: NOKetiqueta: R 5.2etiqueta: chk 10 web

    Evidências:

    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 conteúdo disponibiliza uma representação visual dos dados, sem alternativa textual equivalente, o que impede utilizadores de tecnologias de apoio de compreenderem a informação.

    Image

    URL:
    https://appacdmviseu.pt/respostas-sociais/centro-de-recursos-para-a-inclusao/

    Recomendações:

    • A informação "Psicologia, Terapia da fala, Psicomotricidade, Fisioterapia, Plano individual de transição e terapia ocupacional " deve ser apresentada diretamente no conteúdo da página juntamente com o texto existente.

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #25 Imagem-link com texto alternativo incorreto

    etiqueta: NOKetiqueta: chk 10 webetiqueta: R 5.3

    Verificado que a imagem link está com nome acessível pouco claro. O nome deve descrever o propósito do link, não apenas o conteúdo visual ou nome do ficheiro. Nesse exemplo o link direciona para a página "PROJETO NOVO EDIFÍCIO DESTINADO A C.A.C.I." e o nome acessível do link está como "barra cofinanciada caci":

    Image

    Outro exemplo verificado é a imagem link para voltar para a Homepage que não descreve a ação ou destino do link. Uma alternativa de texto seria: alt="Página inicial APPACDM Viseu".

    Image Image

    URL:
    https://appacdmviseu.pt/
    https://appacdmviseu.pt/junte-se-a-nos/consignacao-irs/

    Recomendações:

    • O texto alternativo deve transmitir claramente o destino ou finalidade do link.

  • issue #18 Existem imagens-link que estão sendo estruturados de forma inapropriada

    etiqueta: NOKetiqueta: chk 10 webetiqueta: R 5.3

    Verifica-se que as imagens da galeria não estão a ser implementadas com elementos <img>, encontrando-se acopladas dentro do link por divs e sendo apresentadas via CSS.

    Esta abordagem faz com que ao desativar o CSS, as imagens deixam de ser apresentadas, o que demonstra que a informação visual não está corretamente estruturada no HTML. Para além disso, nota-se o uso do atributo alt no link, o que está incorreto, pois é um atributo a ser utilizado em elementos img.

    Image

    Outro exemplo é o botão de pesquisa onde o nome acessível está a ser definido através de aria-label="Pesquisar", em vez de ser associado ao atributo alt da imagem. Adicionalmente, o ícone da lupa encontra-se incluído como conteúdo textual (emoji/SVG) no elemento alt, podendo interferir na interpretação do nome acessível. Para além disso, verifica-se a presença de role="img" sem a necessidade, uma vez que essa informação está sendo transmitida pela tag img do HTML.

    Image Image

    Outro exemplo:

    Image

    Verifica-se que os links associados às imagens (ícones de idiomas) utilizam o atributo title para fornecer informação (“English”, “French”, etc.).

    Image
    URL a verificar

    https://appacdmviseu.pt/novo-edificio-destinado-a-caci/
    https://appacdmviseu.pt/projetos/cao-criar-adaptar-e-otimizar-para-mais-qv/
    https://appacdmviseu.pt/respostas-sociais/centro-de-atividades-e-capacitacao-para-a-inclusao/
    https://appacdmviseu.pt/respostas-sociais/centro-de-recursos-para-a-inclusao/
    https://appacdmviseu.pt/respostas-sociais/formacao-profissional/
    https://appacdmviseu.pt/respostas-sociais/lar-residencial/
    https://appacdmviseu.pt/respostas-sociais/residencia-de-autonomizacao-e-inclusao/

    Sugestão de correção

    Recomenda-se a adoção de uma das seguintes abordagens para garantir a acessibilidade das imagens-link:

    1 - Estrutura semântica correta

    • A imagem deve ser implementada como um elemento diretamente no HTML, evitando o uso de CSS em imagens que transmitem informações.
    • A imagem deve estar integrada no link e possuir um atributo alt com texto adequado, garantindo que continua visível e funcional mesmo com o CSS desativado.
    • Deve ainda ser removido o uso de aria-label, evitando redundância no nome acessível.

    2 - Nome acessível correto

    • O texto alternativo deve transmitir claramente o destino ou finalidade do link. No exemplo das imagens ampliadas, o nome do link deve informar a ação a ser realizada (exemplo: Entrada principal exterior ampla - Expandir imagem)

Requisito 6.1 - No corpo de um documento, o rácio de contraste entre a cor do texto normal (menor que 18 pontos ou menor que 14 pontos negrito) e a cor do fundo é superior a 4,5:1

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #34 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

    Notas gerais

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

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

    A página Ofertas de emprego apresenta problemas de contraste com a combinação de cores #A0A0A0 (cor de primeiro plano) e #FFFFFF(cor de plano de fundo) (Figura 1)

    Image

    Figura 1- Página com problemas de contraste em textos normais

    O mesmo acontece na página Apresentação com rácio de contraste inferior ao recomendado. Na combinação de cores #FFFFFF (cor de primeiro plano) e #79ADE1(cor de plano de fundo) (Figura 2)

    Image

    Figura 2- Página “Apresentação” apresenta contraste inferior para texto normal

    Na página Contactos os textos dos endereços de e-mail apresentam baixo rácio de contraste para texto normal. Nas combinações de cores #FFFFFF (cor de primeiro plano) e #9EC222(cor de plano de fundo) com taxa de contraste inferior ao recomendado. (Figura 3)

    Image

    Figura 3- Textos dos emails de contactos com contraste inferior ao recomendado_

    Recomendações
    Recomendamos a revisão das cores das páginas para garantir os valores mínimos de contraste do texto normal.

Requisito 6.2 - O rácio de contraste entre a cor do texto de tamanho grande (maior ou igual que 18 pontos ou maior ou igual que 14 pontos negrito) e a cor do fundo é superior a 3:1

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #35 Textos grandes não tem contraste suficiente

    etiqueta: NOKetiqueta: R 6.2etiqueta: chk 10 web

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

    Notas Gerais

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

    Na página Apresentação o texto grande “Visão” com tamanho de 34px, apresenta problemas de contraste com a combinação de cores #79ADE1(cor de primeiro plano) e #FFFFFF(cor de plano de fundo) (Figura 1)

    Image

    Figura 1- Texto grande de título não passa na avaliação com taxa de contraste (2.36:1)”

    O mesmo problema acontece, na página A nossa história com a timeline histórica que apresenta as datas anuais, com os textos grandes 33px e utilizam a mesma combinação de cores que não passa na avaliação de contraste. (Figura 2)

    Image

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

    Na página Apresentação o texto grande “Visão” com tamanho de 34px, apresenta problemas de contraste com a combinação de cores #FFFFFF(cor de primeiro plano) e #79ADE1(cor de plano de fundo) com taxa de de contraste 2.36:1 (Figura 3)

    Image

    Figura 3- Texto grande do título “Visão” não passa na avaliação de contraste”

    Recomendações


    Recomendamos a revisão das cores das páginas para garantir os valores mínimos de contraste do texto grande, principalmente nos pares de cores indicados mas também em todo o website.

    • Caso exista texto grande com pouco contraste, em que as cores utilizadas sejam as mesmas do logótipo da entidade, recomendamos a substituição dessas cores por outras que garantam um contraste mínimo de 3:1. Por exemplo, podem ser usados tons semelhantes ao do logotipo ou outras cores da identidade gráfica da marca.

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

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

Lista de evidências recolhidas:

  • issue #51 Foi possivel ativar os botões de controlo do leitor quer com o rato quer com o teclado

    etiqueta: chk 10 webetiqueta: R 7.1etiqueta: melhoria

    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:

    Image

    Recomendações:

    É necessário garantir que os controlos 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.

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: NOK

Lista de evidências recolhidas:

Requisito 8.1 - Quando se retira a CSS, todos os elementos HTML devem alinhar à esquerda

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #22 Elementos não alinhados à esquerda quando o CSS é desativado

    etiqueta: NOKetiqueta: chk 10 webetiqueta: R 8.1

    Quando se retira a CSS, todos os elementos HTML devem alinhar à esquerda.
    – ver requisito 8.1 na lista 10 aspetos

    Notas Gerais

    • Quando os estilos CSS são desativados, o conteúdo da página deve ser apresentado de forma linear e alinhado à esquerda. Este comportamento garante que a estrutura base em HTML é consistente, previsível e compreensível sem dependência de estilos visuais.
    • A apresentação linear facilita a leitura sequencial e assegura compatibilidade com diferentes agentes de utilizador e tecnologias de apoio.

    URL a verificar

    Evidências:

    Ao desativar os estilos CSS, verifica-se que o botão de menu surge posicionado do lado direito, não respeitando o alinhamento à esquerda esperado.

    Este comportamento indica que a apresentação do elemento não segue uma estrutura linear simples em HTML, dependendo de estilos para o seu correto posicionamento.

    Image

    Figura 1 – Botão de menu desalinhado quando o CSS é desativado

    Recomendações:

    Recomenda-se que, na ausência de CSS, todos os elementos da página sejam apresentados de forma linear e alinhados à esquerda.

    Para tal, a estrutura HTML deve ser organizada de forma simples e sequencial, evitando dependências de estilos para garantir posicionamento base.

    Adicionalmente, recomenda-se validar a apresentação da página com CSS desativado, assegurando que o conteúdo permanece legível, compreensível e corretamente estruturado.

Requisito 8.2 - Quando se retira a CSS, a informação aparece numa ordem lógica

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #87 Sequência lógica de leitura interrompida

    etiqueta: NOKetiqueta: chk 10 webetiqueta: R 8.2

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

    Notas Gerais

    • Quando o conteúdo é fragmentado em múltiplas listas ou colunas que separam informações relacionadas, utilizadores de tecnologias de apoio perdem o fio condutor da leitura, especialmente se o foco for forçado a saltar entre blocos de código distintos.

    URL a verificar

    Evidências:

    A lista de municípios está dividida em dois blocos (listas separadas) posicionados em colunas laterais, com uma imagem no centro. Sem CSS, o leitor de ecrã processa primeiro a lista da esquerda, depois a imagem (que interrompe o contexto) e, por fim, a lista da direita. Esta fragmentação impede que a lista seja lida como um conjunto coeso de informação, quebrando a sequência lógica de leitura.

    Image

    Figura 1 – Estrutura fragmentada da lista de municípios (duas listas distintas separadas por uma imagem no DOM)

    Recomendações:

    • Unificar o DOM: A estrutura deve ser unificada numa única lista (<ul>), mantendo a integridade da informação, independentemente de como o CSS irá distribuir os itens visualmente no ecrã.
    • Ordem lógica: Garantir que, ao desativar o CSS, o utilizador leia a lista completa de municípios de forma linear e contínua, sem a interrupção da imagem no meio da sequência.
    • Semântica: Confirmar que todos os elementos de lista (<li>) fazem parte da mesma hierarquia, facilitando a navegação por tecnologias de apoio.

  • issue #77 A ordem de leitura não é a que está sendo apresentada visualmente

    etiqueta: NOKetiqueta: chk 10 webetiqueta: R 8.2

    Quando se navega com o teclado ou com um leitor de ecrã pelas opções da página, não é possível alterar o idioma. Embora a funcionalidade de mudança de idioma seja apresentada visualmente no topo da página, a sua posição estrutural encontra‑se após todo o conteúdo e, inclusivamente, fora da região main:

    Image

    Quando o CSS é desativado, as opções de idioma deixam de ser visíveis. Isto acontece porque as bandeiras de cada idioma estão a ser inseridas exclusivamente via CSS e, adicionalmente, o nome acessível está a ser fornecido através do atributo title. Esta abordagem não é recomendada, uma vez que o title deve ser utilizado apenas para transmitir informação complementar e não para comunicar informação essencial, como o nome do link:

    Image

    URL

    Sugestão de correção

    • Posicionar estruturalmente a opção de idiomas após os links das redes sociais que estão sendo apresentadas no topo da página, garantindo que a ordem lógica corresponde à ordem visual.
    • Alterar o nome “Translate” para “Idiomas da página”, para clarificar o propósito da funcionalidade.
    • Os links de cada idioma devem incluir um nome acessível fornecido através de texto oculto visualmente, mas disponível para tecnologias de apoio. Para mais informações, podem consultar o artigo: https://www.acessibilidade.gov.pt/tutorial/css-em-accao-conteudo-invisivel-apenas-para-utilizadores-de-leitor-de-ecra/

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #83 Inconsistência semântica nos controlos de formulário

    etiqueta: NOKetiqueta: chk 10 webetiqueta: R 8.3

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

    Notas Gerais:

    • Os elementos que estruturam o conteúdo devem estar semanticamente corretos, utilizando os elementos HTML apropriados para cada função.
    • O uso de componentes semânticos corretos (como radio buttons para escolhas exclusivas) é fundamental para que os utilizadores compreendam a natureza da interação, especialmente em tecnologias de apoio, que comunicam a função e o estado destes elementos.
    • A utilização de checkboxes para escolhas onde apenas uma opção é permitida (mutuamente exclusivas) induz o utilizador em erro quanto ao comportamento esperado do sistema.

    URL a verificar:

    Evidências:

    No formulário, os grupos de opções "Escolha uma opção" (Sugestão/Elogio/Reclamação) e "Esta sugestão / elogio / reclamação é de um" estão implementados com checkboxes. Em ambos os casos, a lógica de negócio exige uma seleção exclusiva (apenas uma opção pode ser selecionada), mas o controlo atual não reflete este comportamento, sendo semanticamente incorreto.

    Image

    Figura 1 – Grupo de opções de seleção no formulário

    Recomendações:

    • Alterar o tipo de controlo de checkbox para radio button (utilizando <input type="radio"> dentro de um grupo <fieldset> com a respetiva <legend>).
    • Garantir que todos os radio buttons do mesmo grupo partilhem o mesmo atributo name para que a exclusividade da seleção seja assegurada nativamente pelo navegador.

  • issue #45 Listagem de conteúdos não estruturada semanticamente como lista

    etiqueta: NOKetiqueta: chk 10 webetiqueta: R 8.3

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

    Notas Gerais

    • Conteúdos que representam conjuntos de itens relacionados, como listagens de notícias, serviços ou outros conteúdos apresentados em formato de “cards”, devem ser estruturados com elementos HTML semânticos apropriados, como listas (<ul> / <ol> e <li>), de forma a garantir que as tecnologias de apoio conseguem identificar corretamente o agrupamento e o número de elementos.
    • A ausência desta estrutura compromete a perceção da relação entre os conteúdos apresentados.

    URL a verificar

    Evidências:

    Na página inicial, existem vários conjuntos de conteúdos apresentados visualmente em formato de grelha (cards), nomeadamente nas secções de Respostas Sociais, Notícias ou “Junte-se a nós”.

    Na secção de Notícias, cada item (imagem, título, descrição e data) é estruturado com elementos como <article> e <div>, mas não está inserido numa lista semântica (<ul>/<li>), o que impede que a relação entre os vários itens seja programaticamente identificada como um conjunto.

    De forma semelhante, na secção “Junte-se a nós”, as diferentes opções (IRS, Candidatura Espontânea, Donativos, Associados, Voluntariado) são apresentadas como blocos independentes, também construídos com <div>, sem qualquer estrutura que indique que fazem parte de um grupo relacionado.

    Quando os estilos CSS são desativados, estes conteúdos deixam de ser percebidos como listas ou conjuntos organizados, dificultando a compreensão da estrutura e da relação entre os elementos.

    Este padrão repete-se em várias áreas do website, indicando um problema transversal na estrutura semântica.

    Image

    Figura 1 – Listagem de notícias estruturada com <div> e <article> sem utilização de lista semântica

    Image

    Figura 2 – Secção “Junte-se a nós” estruturada com <div> sem utilização de lista semântica

    Recomendações:

    Recomenda-se que conjuntos de conteúdos relacionados sejam estruturados utilizando elementos semânticos apropriados, nomeadamente listas (<ul> ou <ol>), onde cada item é representado por um <li>.

    Esta abordagem permite que tecnologias de apoio interpretem corretamente a relação entre os elementos e melhora a compreensão da estrutura da página quando os estilos visuais não estão presentes.

    Para orientação sobre boas práticas na estruturação semântica de conteúdos, recomenda-se a consulta da documentação do W3C:
    https://www.w3.org/WAI/tutorials/page-structure/content/#lists

    Adicionalmente, recomenda-se a revisão deste padrão em todo o website, uma vez que este tipo de componente (cards/listagens) tende a ser reutilizado em várias páginas. Deve ser validado com leitores de ecrã para garantir que o agrupamento e a navegação entre itens são corretamente comunicados.

  • issue #43 Título do modal não é reconhecido semanticamente

    etiqueta: NOKetiqueta: chk 10 webetiqueta: R 8.3

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

    Notas Gerais

    • Os títulos são fundamentais para estruturar o conteúdo e permitir a sua correta interpretação por tecnologias de apoio. Em componentes como modais, o título deve estar visível e semanticamente identificado, de forma a fornecer contexto ao utilizador sobre o conteúdo apresentado.
    • A utilização incorreta ou ocultação de títulos compromete a compreensão da interface, especialmente quando os estilos visuais são desativados.

    URL a verificar

    Evidências:
    No modal apresentado ao carregar a página, existe um título implementado como elemento <h2> com o texto “IRS”. No entanto, este encontra-se oculto através do CSS.
    Desta forma:

    • O título não é visível para os utilizadores;
    • Ao remover os estilos CSS, o comportamento pode ser inconsistente;
    • O título não é utilizado como referência semântica da modal (por exemplo, através de aria-labelledby);
    • A ausência de um título visível compromete a identificação do conteúdo da modal.

    Como consequência, não é possível reconhecer claramente o propósito da modal nem a sua estrutura semântica.

    Image

    Figura 1 – Título da modal oculto e não utilizado como elemento semântico identificador

    Recomendações:

    Recomenda-se que o título da modal seja apresentado de forma visível e estruturado com um elemento semântico adequado (por exemplo, <h2>), garantindo que descreve claramente o conteúdo apresentado.

    O título deve também ser associado à modal como nome acessível, através do atributo aria-labelledby, permitindo que tecnologias de apoio identifiquem corretamente o contexto do diálogo.

    Deve ser evitada a ocultação do título com display: none, exceto em casos devidamente justificados, garantindo sempre a sua disponibilidade para todos os utilizadores.

    Por fim, recomenda-se validar o comportamento com CSS desativado e com leitores de ecrã, assegurando que o título é corretamente apresentado e interpretado.

  • issue #37 Modal com estrutura semântica insuficiente

    etiqueta: NOKetiqueta: chk 10 webetiqueta: R 8.3

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

    Notas Gerais:

    • Quando o CSS é desativado, a estrutura da página deve permanecer compreensível, identificando corretamente a semântica e a função dos elementos.
    • Modais devem ser implementados utilizando elementos nativos (<dialog>) e atributos semânticos (aria-labelledby), garantindo que a sua finalidade, título e conteúdo sejam expostos às tecnologias de apoio.
    • A dependência de elementos genéricos (<div>) para criar componentes interativos prejudica a navegação e a perceção de hierarquia, tornando o conteúdo inacessível para utilizadores de leitores de ecrã.

    URL a verificar:

    Evidências:

    O modal apresentado é construído com elementos genéricos (<div>), o que impossibilita a sua interpretação sem estilos visuais e bloqueia o acesso através de leitores de ecrã:

    1. Inacessibilidade total: O conteúdo do modal não é detetado/acessível via leitor de ecrã.
    2. Semântica inadequada: O botão de fechar é um <div> com conteúdo textual ("✕") em vez de um elemento <button> semântico.
    3. Falta de nome acessível: O modal não possui uma relação programática com o seu título, falhando em identificar a sua finalidade.
    4. Problema de usabilidade (Temporizador): A modal apresenta um fecho automático/temporizador que não é configurável, impedindo utilizadores que necessitam de mais tempo de leitura de aceder à informação.
    Image

    Figura 1 – Estrutura do modal com falta de semântica e botões não acessíveis

    Recomendações:

    • Estrutura semântica: Substituir a implementação atual pela tag nativa <dialog>, garantindo que o componente seja corretamente identificado pelo navegador e tecnologias de apoio.
    • Nome acessível: Utilizar o atributo aria-labelledby na tag <dialog>, associando-o ao id do título (<h2>) da modal para garantir a sua identificação programática.
    • Controlos interativos: Substituir elementos <div> por <button> para todas as ações (como o fechar), garantindo que a sua função seja interpretada corretamente mesmo sem CSS.
    • Gestão de tempo: Remover o fecho automático da modal ou implementar um mecanismo que permita ao utilizador pausar ou prolongar o tempo de visualização, respeitando as necessidades de acessibilidade de leitura.

Requisito 8.4 - Quando se retira a CSS, a informação relevante permanece visível

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #86 Conteúdo textual inserido via CSS e falha de localização

    etiqueta: R 8.4etiqueta: chk 10 webetiqueta: melhoria

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

    Notas Gerais

    • Toda a informação visível deve estar presente na estrutura HTML da página. A utilização de CSS para inserir texto (conteúdo) é uma prática incorreta, uma vez que esta informação deixa de estar disponível quando os estilos visuais são desativados.
    • Além da semântica, o conteúdo textual deve respeitar o idioma da página. A presença de texto em inglês ("Read more") num site em português compromete a acessibilidade cognitiva e a consistência da experiência do utilizador.

    URL a verificar

    Evidências:

    O link de navegação "Ler mais" está implementado via CSS e o texto "Read more" está estruturado no HTML e escondido visualmente. Ao desligar o CSS o texto em português desaparece e mantém apenas o texto que está na estrutura, com o idioma em inglês:

    Image

    Figura 1 – Link de "Read more" no código HTML sem a devida localização

    Recomendações:

    • Correção de Idioma: Substituir o texto "Read more" no ficheiro de tradução do tema por "Ler mais", garantindo que a versão portuguesa do site apresente o texto correto.
    • Contexto Acessível: Para melhorar a acessibilidade, o link pode incluir um texto oculto que especifique o título da notícia (ex: "Ler mais sobre [Título da Notícia]") utilizando uma classe de acessibilidade sr-only, para que utilizadores de leitores de ecrã saibam exatamente para onde o link direciona.

  • issue #27 Conteúdo do menu não visível sem CSS

    etiqueta: NOKetiqueta: R 8.4etiqueta: chk 10 web

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

    Notas Gerais

    • Quando os estilos CSS são desativados, toda a informação relevante deve permanecer visível na página em formato textual, garantindo que o utilizador consegue aceder ao conteúdo independentemente da apresentação visual.
    • A ocultação de informação essencial através de estilos pode comprometer o acesso ao conteúdo e impedir a compreensão da estrutura da página.

    URL a verificar

    Evidências:

    Ao desativar os estilos CSS, verifica-se que os submenus da navegação principal não são apresentados de forma visível.

    Apesar de estarem presentes no código HTML, os elementos de submenu (<ul>) encontram-se ocultos através de estilos inline como opacity: 0 e visibility: hidden, o que impede a sua visualização
    Este comportamento faz com que parte da informação não seja apresentada de forma imediata e linear, comprometendo a compreensão da estrutura de navegação.

    Image

    Figura 1 – Submenu oculto com opacity: 0 e visibility: hidden, não visível sem CSS

    Recomendações:

    Recomenda-se que a informação relevante da navegação permaneça sempre visível em formato textual quando os estilos CSS são desativados.

    Deve ser evitada a ocultação de elementos essenciais através de propriedades como visibility: hidden, opacity: 0 ou display: none, quando estas impedem a apresentação da informação em modo não estilizado.

    Sugere-se ainda a implementação de menus que mantenham a estrutura textual visível e linear sem dependência de estilos, garantindo a acessibilidade da navegação em diferentes contextos.

    Adicionalmente, recomenda-se validar o comportamento da página com CSS desativado para garantir a conformidade com este critério.

Requisito 9.1 - Quando a caixa de diálogo é aberta, o foco (cursor do Browser) move-se para um elemento dentro da caixa de diálogo

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #36 Modal não esta acessível por tecnologias de apoio

    etiqueta: NOKetiqueta: chk 10 webetiqueta: R 9.1

    Evidências:

    Verifica-se que a modal não se encontra acessível a tecnologias de apoio (teclado, leitor de ecrã). Ao ser apresentada, não é anunciada pelos leitores de ecrã e o foco não é direcionado para o conteúdo da modal.

    Image

    URL:

    https://appacdmviseu.pt/

    Recomendações:

    • Deve ser garantido que, ao abrir a modal, o foco é automaticamente direcionado para o seu conteúdo, preferencialmente para o primeiro elemento interativo.

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #38 Foco não fica limitado a modal

    etiqueta: NOKetiqueta: chk 10 webetiqueta: R 9.2

    Evidências:
    Verifica-se que, ao abrir a janela modal o foco de navegação não fica limitado ao seu conteúdo. Durante a navegação, é possível interagir com elementos subjacentes à modal, fora do seu contexto.

    Image

    URL:
    https://appacdmviseu.pt

    Recomendações:

    • Garantir que o foco fica limitada ao conteúdo da modal até seu encerramento.

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #69 Não é possível fechar a modal com o teclado ou leitor de ecrã

    etiqueta: NOKetiqueta: chk 10 webetiqueta: R 9.3

    Verificado que quando a modal da homepage esta aberta, o foco não é posicionado no primeiro elemento que é o botão fechar, impedindo que a modal seja fechada utilizando teclado ou leitor de ecrã.

    Image

    URL:

    https://appacdmviseu.pt/

    Recomendações:

    • Deve ser possível sair ou fechar a modal, quer através de teclado quer através de um dispositivo apontador.
    • Recomenda-se que o foco seja direcionado para o primeiro elemento ao aceder a modal.

Requisito 9.4 - Quando a caixa de diálogo fecha, o foco (cursor do Browser) deve voltar ao elemento interativo que a invocou

etiqueta: NOK

Lista de evidências recolhidas:

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:

  • issue #53 Utilização de PDFs com texto em formato de imagem (não extraível)

    etiqueta: NOKetiqueta: chk 10 webetiqueta: R 10.1

    No website da instituição, foram identificados vários documentos PDF cujo conteúdo textual se encontra incorporado como imagens (resultantes de digitalização), impossibilitando a sua extração e leitura por tecnologias de apoio.

    Na página de documentação (ver Figura 1), diversos links apontam para ficheiros PDF compostos exclusivamente por imagens digitalizadas (assinalados a vermelho). Adicionalmente, alguns documentos (assinalados a amarelo) contêm uma mistura de texto acessível e elementos em formato de imagem com texto embutido.

    Image

    Figura 1: Imagem da página de documentação da instituição com diversos pdf's

    Nestes últimos casos, embora parte do conteúdo seja tecnicamente acessível, existem elementos críticos — como organogramas (Figura 2) e tabelas (Figura 3) — que apresentam informação textual exclusivamente em formato de imagem, não sendo interpretáveis por leitores de ecrã nem permitindo seleção/copiar texto.

    Image

    Figura 2: Organograma geral estrutural no formato de imagem.

    Image

    Figura 3: Tabela com texto no formato de imagem.

    Foi ainda identificado outro caso semelhante na página das ementas (nomeadamente o documento “EMENTA DO ESTABELECIMENTO DE SANTA COMBA DÃO”), que consiste inteiramente em imagens digitalizadas.

    Recomendações:

    • Substituir os PDFs digitalizados por versões com texto real (ex.: documentos gerados digitalmente).
    • Aplicar [Reconhecimento Óptico de Caracteres (OCR) da Adobe](https://www.adobe.com/pt/acrobat/how-to/ocr-software-convert-pdf-to-text.html aos documentos existentes, garantindo que o texto seja pesquisável e acessível.
    • Evitar o uso de imagens para representar texto, especialmente em tabelas, organogramas e conteúdos informativos.
    • Garantir que todos os documentos PDF cumprem boas práticas de acessibilidade (tags, estrutura semântica, leitura lógica).

Checklist Conteúdo

etiqueta: NOK

Nível de conformidade:

  • Checklist Conteúdo: 17.6% (3/17)
    • Requisitos avaliados: 17 (17 aplicáveis)
    • Requisitos OK: 3
    • Requisitos NOK: 14

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #3 Falta de resumo presente na página inicial

    etiqueta: NOKetiqueta: chk conteúdoetiqueta: R 1.1

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

    Evidências:

    Na página inicial do APPACDM Viseu, https://appacdmviseu.pt/, não aparece presente um resumo breve do próposito do site.

    Image

    Imagem da página inicial sem dar scroll.

    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 inicial, sem ser necessário fazer scroll, avançar no slideshow, entre outros.

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

    Image

    Image exemplo de uma frase de propósito do website acessibilidade.gov

Requisito 1.2 - Os termos mais complexos têm uma definição agregada

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #14 Falta 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:
    A análise do website revelou dificuldades na compreensão de conteúdos devido à utilização frequente de siglas e termos complexos que não são devidamente explicados no momento em que surgem. Por exemplo, a sigla “APPCDM” é utilizada de forma recorrente ao longo do website, mas a sua definição apenas pode ser encontrada na secção de apresentação, obrigando o utilizador a navegar adicionalmente para compreender o seu significado.

    De forma semelhante, outras siglas como “BPI” e “ONG” são apresentadas sem qualquer explicação contextual, o que pode comprometer a compreensão, especialmente para utilizadores menos familiarizados com estes termos. Esta prática aumenta a carga cognitiva e dificulta o acesso à informação.

    Image

    Imagem do termo complexo "BPI", disponível em: https://appacdmviseu.pt/projetos/cafetaria-docemente-ii/

    Image

    Imagem do rodapé com vários termos complexos como "APPCDM" e "ONG"

    Neste caso, o uso é inadequado, pois a sigla “CACI” é utilizada antes de ser apresentada a sua definição, que apenas surge posteriormente na página.

    Image

    Imagem com o termo complexo "CACI", disponível em: https://appacdmviseu.pt/novo-edificio-destinado-a-caci/

    Recomendações:

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

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

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #4 Ausência de datas de atualização nos conteúdos

    etiqueta: NOKetiqueta: chk conteúdoetiqueta: R 1.3

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

    Evidências:

    Existem vários blocos de conteúdo que não apresentam informação clara sobre a sua data de atualização. Como por exemplo:

    Image

    Imagem de evidência da página de contactos sem data de atualização.

    A ausência desta informação dificulta a perceção da atualidade dos conteúdos por parte dos utilizadores, podendo levar à interpretação de informação desatualizada como sendo atual. A falta de metadados estruturados (como datas) compromete a correta interpretação do conteúdo, especialmente por tecnologias de apoio, e reduz a clareza semântica exigida pelo critério.

    Recomendações:

    • Incluir a data de publicação e/ou última atualização em todos os conteúdos relevantes;

    • Garantir que essa informação está semanticamente estruturada;

    • Assegurar consistência na apresentação das datas em todo o site.

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #5 Falta dos direitos da entidade responsável e hiperligação para os contactos

    etiqueta: NOKetiqueta: chk conteúdoetiqueta: R 1.4

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

    Evidências:

    O rodapé do website não apresenta a identificação da entidade responsável pelo conteúdo disponibilizado. Além disso, a secção de contactos encontra-se incompleta, contendo apenas informação parcial e sem ligação direta para a página dedicada aos contactos. Esta limitação pode dificultar o acesso dos utilizadores a informações essenciais e reduzir a transparência e a confiança no website.

    Image

    Imagem do rodapé sem a informação da entidade responsável.

    Recomendações:
    Deve ser incluída no rodapé a identificação completa da entidade responsável pelo website, acompanhada dos respetivos direitos. Adicionalmente o rodapé deve incluir uma hiperligação visível e funcional para a página de contactos, garantindo assim um acesso simples, consistente e intuitivo para todos os utilizadores.

    Como exemplo de uma boa prática, é possível verificar no website acessibilidade.gov como que os direitos e a hiperligação para os contactos deve ser apresentados:

    Image

    Imagem do rodapé do acessibilidade.gov com os direitos e hiperligação para os contactos.

Requisito 2.1 - O tipo de letra do corpo do documento é adequado e o tamanho da letra é, no mínimo, de 12 pontos

etiqueta: NOK

Lista de evidências recolhidas:

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

    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 12pontos(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 ao recomendado. As opções de primeiro nível do menu com 14px e as opções de segundo nível do menu com 12px. (Figura 1)

    Image

    Figura 1 - Verificação do tamanho do texto das opções do menu com tamanho inferior ao recomendado.

    Além disso, há componentes com informações primárias por exemplo texto dos cookies, como os botões da modal de cookies “Aceitar”, “Rejeitar” e “Política de Privacidade”, possuem textos com 13px, dimensão inferior ao recomendado. (Figura 2)

    Image

    Figura 2 - Verificação do tamanho de texto para aceitação dos cookies na página inicial

    O mesmo acontece em blocos de textos e botões de páginas interiores:

    Recomendação de melhoria
    É necessário rever todo o corpo de texto do website, além das evidências aqui apontadas, corrigir todos os textos de informações primárias, para um tamanho igual ou superior ao recomendado.

Requisito 2.2 - A informação secundária (datas, autores) utiliza, no mínimo, um tamanho de letra de 10 pontos

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #7 A informação secundária tem um tamanho de letra inferior a 10pt (equivalente a 13px)

    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 metainformação, podem usar tamanhos de letra mais pequenos, mas, no mínimo, com 10 pontos(13px), 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.

    Por exemplo, na página inicial, a secção “Quem somos” possui texto de informações secundárias com apenas 10px de dimensão, valor não cumpre o presente critério. 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)

    Image

    Figura 1 - Verificação do tamanho do texto “números referentes a 2025”

    As informações secundárias da página de Notícias, como textos dos botões da paginação possuem dimensão inferior ao recomendado com 11px. (Figura 2)

    Image

    Figura 2 - Verificação do tamanho do texto na componente de paginação

    Outro exemplo é no "Formulário de pesquisa" que apresenta a pesquisa em um dropdown com textos e informações secundárias. No entanto, possuem tamanho inferior ao recomendado com 12px. (Figura 3)

    Image

    Figura 3 - Verificação de informações secundárias no formulário de pesquisa

    Datas das notícias na página de Pesquisa com tamanho inferior ao recomendado.

    Outras páginas com o mesmo problema:

    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;

Requisito 2.4 - O espaçamento entre linhas não é inferior a 1.5x o tamanho da letra

etiqueta: NOK

Lista de evidências recolhidas:

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #30 Hiperligações sem indicação visual

    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:

    A análise do rodapé (figura 1) demonstra que não é possível distinguir claramente se determinados elementos são texto simples ou hiperligações, obrigando o utilizador a recorrer ao uso do rato (hover) para obter uma indicação visual. Esta abordagem limita a perceção imediata dos elementos interativos e pode comprometer a navegação, especialmente para utilizadores que não utilizam dispositivos apontadores.

    Image

    Figura 1: Imagem do rodapé e seus elementos clicáveis e de texto.

    Na Figura 2, também é possível observar hiperligações que não são imediatamente identificáveis como tal, tornando-se visíveis apenas quando o cursor do rato passa sobre elas (hover).

    Image

    Figura 2: Imagem de contéudo na página principal com hiperligações apenas visível com hover.

    Nas imagens seguintes, observa-se que as hiperligações no corpo do texto são identificadas apenas através da cor. No entanto, existem outros elementos com cores semelhantes, o que pode gerar confusão entre texto comum e links, dificultando a identificação correta das áreas clicáveis.

    Image

    Figura 3: Imagem da página Consignação IRS com hiperligações no texto.

    Image

    Figura 4: Imagem da página de acessibilidade com hiperligações no texto.

    Recomendações:

    Deve ser garantido que as hiperligações sejam visualmente distinguíveis do restante texto sem depender exclusivamente da cor ou de interações como o hover. Para isso, recomenda-se a utilização de indicadores adicionais, como sublinhado persistente, estilos tipográficos diferenciados ou outros elementos visuais consistentes, assegurando que os utilizadores conseguem identificar claramente os elementos interativos em qualquer contexto.

    Como exemplo podem visualizar o acessibilidade.gov.pt que utiliza a cor e sublinhado em todos as suas hiperligações no texto.

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 4.2 - O layout do sítio Web é adaptável a plataformas móveis sem necessidade de efetuar varrimento horizontal

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #12 Os conteúdos do site não se adaptam às diferentes resoluções de ecrãs

    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
    Página: https://appacdmviseu.pt/

    Ao utilizar a funcionalidade de pesquisa em dispositivos móveis (ex: iPhone 12 Pro) e realizar scroll na página, alguns elementos do header permanecem fixos (ex: botão de tradução e menu), resultando em sobreposição visual com o campo de pesquisa e conteúdo da página.

    O problema também foi observado em tablets (ex: iPad mini), onde o layout sofre deslocamentos e sobreposição entre componentes do header.

    Header fixo em mobile sobrepondo campo de pesquisa e conteúdo da página durante scroll

    Recomendação

    Rever o comportamento do header em mobile e tablet para evitar que os elementos fixos (menu, tradução e pesquisa) se sobreponham durante o scroll.

    Idealmente, ajustar o layout responsivo para organizar ou reduzir estes elementos em ecrãs menores, garantindo uma interação mais limpa e sem conflitos visuais.

    Ponto 02
    Página: https://appacdmviseu.pt/projetos/banco-de-tecnologias-de-apoio/

    Foi identificado que, em determinados dispositivos móveis, os elementos dos cards não se adaptam corretamente ao ecrã.

    Observa-se que os botões “Abrir” e alguns títulos ultrapassam os limites dos respetivos cards, ficando parcialmente fora da área visível do componente. Este comportamento compromete a consistência do layout e pode afetar a perceção e interação com os elementos.

    Botões do banner de cookies com igual destaque visual entre ações primárias e secundárias

    Recomendação
    Recomenda-se rever o comportamento responsivo dos cards na página, garantindo que todos os elementos (títulos e botões) se mantêm dentro dos limites do componente em diferentes tamanhos de ecrã.

    Deve ser assegurada a adaptação adequada do layout em dispositivos móveis, evitando sobreposição ou saída de conteúdo fora dos containers.

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

etiqueta: NOK

Lista de evidências recolhidas:

Requisito 5.2 - Os elementos interativos têm uma dimensão mínima de 44px CSS (44 pontos) (vertical e horizontal)

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #15 Elementos interativos abaixo do tamanho 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://appacdmviseu.pt/#av_section_1
    Foi identificado um botão flutuante de “voltar ao topo” que surge durante o scroll com dimensões aproximadas de 43px, abaixo do tamanho mínimo recomendado para elementos interativos.

    Este tamanho reduzido pode dificultar a interação, especialmente em dispositivos móveis ou para utilizadores com menor precisão motora.

    Pop-up de campanha IRS sem botão de ação principal destacado

    Recomendação

    Aumentar a área clicável do botão “voltar ao topo” para, no mínimo, 44x44px, garantindo maior facilidade de interação em diferentes dispositivos.

    Ponto 02
    Página: https://appacdmviseu.pt/

    Os ícones de redes sociais presentes no rodapé da página possuem dimensões aproximadas de 20px, ficando abaixo do tamanho mínimo recomendado para elementos interativos (44x44px).

    Botão flutuante “voltar ao topo” com dimensão reduzida (~43px), abaixo do mínimo recomendado de 44px, podendo dificultar a interação em dispositivos móveis

    Recomendação

    Recomenda-se aumentar a área clicável dos ícones de redes sociais para, no mínimo, 44x44px, garantindo maior facilidade de interação em diferentes dispositivos.

    Ponto 03
    Página: https://appacdmviseu.pt/apresentacao/orgaos-sociais/

    Ao abrir o modal de visualização do “Organograma Geral Estrutural”, o botão de fechar (“X”) apresenta dimensões inferiores ao mínimo recomendado para elementos interativos.

    Em desktop, o elemento possui aproximadamente 40px, e em dispositivos móveis reduz para cerca de 32px, ficando abaixo do mínimo de 44x44px recomendado para garantir uma interação acessível e confortável.

    Botões de ação no banner de cookies com hierarquia visual inconsistente, onde “Aceitar”, “Rejeitar” e “Política de Privacidade” apresentam o mesmo nível de destaque

    Recomendação

    Recomenda-se aumentar a área clicável do botão de fechar do modal para, no mínimo, 44x44px, garantindo maior facilidade de interação em desktop e dispositivos móveis.

    Deve também ser assegurado que a área de toque se mantém consistente em todos os breakpoints.

    Ponto 04
    Página: https://appacdmviseu.pt/projetos/banco-de-tecnologias-de-apoio/canadianas/

    No formulário da página, o checkbox de autorização apresenta uma dimensão aproximada de 13px, ficando significativamente abaixo do tamanho mínimo recomendado para elementos interativos (44x44px).

    Pop-up de campanha de consignação IRS sem botão de ação principal claramente destacado, apresentando apenas informação textual e dados (NIF) sem ação direta associada

    Outros exemplos encontrados:
    https://appacdmviseu.pt/projetos/banco-de-tecnologias-de-apoio/andarilho/
    https://appacdmviseu.pt/projetos/banco-de-tecnologias-de-apoio/outros/
    https://appacdmviseu.pt/projetos/banco-de-tecnologias-de-apoio/alimentacao/

    Recomendação
    Recomenda-se aumentar a área clicável do checkbox de autorização para, no mínimo, 44x44px, garantindo maior facilidade de interação em diferentes dispositivos e contextos de utilização.

    Deve também ser assegurado que o espaço de clique não dependa apenas do elemento visual pequeno, mas sim de uma área acessível maior associada ao campo.

    Ponto 05
    Página: https://appacdmviseu.pt/junte-se-a-nos/candidatura-espontanea/

    Na página de candidatura espontânea, os elementos de seleção do formulário (checkboxes) apresentam dimensões inferiores ao mínimo recomendado de 44px.

    Este comportamento verifica-se em múltiplos campos, como nas opções de tipo de candidatura e nas áreas de interesse.

    A reduzida área de interação pode dificultar a seleção, especialmente em dispositivos móveis ou para utilizadores com menor precisão moto

    Image

    Botão flutuante de “voltar ao topo” com foco visível por teclado e indicação de interatividade, mas com dimensão inferior ao mínimo recomendado de 44x44px

    Recomendação:
    Recomenda-se aumentar a área clicável dos elementos de seleção (checkboxes) para, no mínimo, 44x44px, garantindo maior facilidade de interação.

Requisito 5.3 - Há apenas um botão de ação principal por página e o mesmo encontra-se destacado

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #8 Elementos interativos com ausência de destaque claro para 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://appacdmviseu.pt/
    No banner de cookies, os botões “Aceitar”, “Rejeitar” e “Política de Privacidade” surgem com igual destaque, comprometendo a hierarquia visual e dificultando a tomada de decisão por parte do utilizador.

    Banner de cookies com botões “Aceitar”, “Rejeitar” e “Política de Privacidade” apresentados com igual destaque visual, sem hierarquia clara entre ação principal e ações secundárias

    Recomendação:

    • Definir apenas um botão de ação principal com maior destaque visual.
    • Diferenciar visualmente as restantes ações como secundárias (ex: botão outline, link ou cor menos destacada).
    • Garantir uma hierarquia clara e consistente entre ações primárias e secundárias em toda a interface.

    Ponto 02
    Página: https://appacdmviseu.pt/junte-se-a-nos/ofertas-emprego/

    Na página, foram identificados dois botões de ação — “Ver oferta” e “Enviar email” — apresentados com o mesmo nível de destaque visual.

    Apesar de corresponderem a ações distintas, não existe diferenciação entre ação principal e secundária, o que pode dificultar a perceção da hierarquia e da prioridade de interação por parte do utilizador.

    Pop-up de campanha de consignação IRS sem botão de ação principal claro, apresentando apenas informação textual e NIF sem interação direta evidente para o utilizador

    Outros exemplos encontrados:
    https://appacdmviseu.pt/junte-se-a-nos/associados/
    https://appacdmviseu.pt/apresentacao/ementas/

    Recomendação
    Recomenda-se definir uma hierarquia clara entre os botões apresentados, destacando visualmente a ação principal (ex: “Enviar email”) e apresentando a restante como ação secundária.

    A diferenciação pode ser feita através de cor, estilo ou outro recurso visual consistente com o restante site.

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

etiqueta: NOK

Lista de evidências recolhidas:

Checklist Transação

etiqueta: NOK

Nível de conformidade:

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

Requisito 1.1 - A sequência de tabulação entre campos segue a sequência de preenchimento

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #39 Caixas de seleção sem rótulo anunciado ao receber foco

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

    A sequência de tabulação entre campos segue a sequência de preenchimento.
    – ver requisito 1.1 na lista Transação

    Verificámos que, nos formulários que utilizam caixas de seleção (checkboxes), os respetivos rótulos não são anunciados quando o utilizador navega com Tab ou Shift+Tab. Isto pode ser especialmente confuso para utilizadores que navegam pela página através de tecnologias de apoio.

    Recomendamos que a estrutura destes campos seja restruturada. Deve ser criado um elemento

    que contenha todas as caixas de seleção. Dentro deste elemento
    , o elemento deve conter o rótulo do grupo (por exemplo, “Indique a sua disponibilidade: (obrigatório)”.

    Exemplo de código acessível para checkboxes:

    <fieldset>
<legend>Select your pizza toppings:</legend>
<input id="ham" type="checkbox" name="toppings" value="ham">
<label for="ham">Ham</label><br>
<input id="pepperoni" type="checkbox" name="toppings" value="pepperoni">
<label for="pepperoni">Pepperoni</label><br>
<input id="mushrooms" type="checkbox" name="toppings" value="mushrooms">
<label for="mushrooms">Mushrooms</label><br>
<input id="olives" type="checkbox" name="toppings" value="olives">
<label for="olives">Olives</label>
</fieldset>

    Podem consultar o artigo da WebAIM Creating Accessible Forms para mais informações.

    URL’s a verificar:

    Image

    Figura 1 - Navegação no formulário da página Candidatura Espontânea através de leitor de ecrã e Tab e Shift+Tab.

    Image

    Figura 2 - Navegação no formulário da página Voluntariado através de leitor de ecrã e Tab e Shift+Tab.

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #40 Existem formulários longos sem divisão por passos

    etiqueta: NOKetiqueta: chk transaçãoetiqueta: 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 Voluntariado, Candidatura Espontânea e SUGESTÕES, ELOGIOS E RECLAMAÇÕES existem formulários longos onde é pedida toda a informação ao utilizador de uma só vez.

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

    Image

    Figura - Página Voluntariado. O formulário presente na página está destacado através de um retângulo de borda roxa.

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

etiqueta: N/A

Lista de evidências recolhidas:

  • issue #41 Não foram encontrados formulários com mais de uma página

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

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

    Não foram encontrados formulários com mais de uma página dentro do site da APPACDM Viseu. Assim, este requisito é avaliado como "Não aplicável".

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

etiqueta: NOK

Lista de evidências recolhidas:

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

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

    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 dos formulários das páginas Voluntariado, SUGESTÕES, ELOGIOS E RECLAMAÇÕES, Contactos e Candidatura Espontânea, a largura dos campos não reflete o tamanho previsível dos dados. Os campos são demasiado largos para a informação inserida, dando a entender que se pode escrever mais.

    Recomendamos a revisão dos campos dos formulários, garantindo que a largura dos campos está adequada ao tipo de informação a inserir.

    Páginas e respetivos campos de formulário a restruturar:

    Voluntariado

    • Concelho
    • Contacto telefónico
    • Email

    SUGESTÕES, ELOGIOS E RECLAMAÇÕES

    • Contacto telefónico
    • Email

    Contactos

    • Email
    • Assunto

    Candidatura Espontânea

    • Concelho
    • Contacto telefónico
    • Email
    Image

    Figura - Formulário da página SUGESTÕES, ELOGIOS E RECLAMAÇÕES onde os campos "Contacto telefónico" e "Email" têm, inadequadamente, a mesma largura que o campo "Nome".

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

etiqueta: N/A

Lista de evidências recolhidas:

  • issue #44 Não foram identificados formulários que utilizem revelação progressiva

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

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

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

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

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

Lista de evidências recolhidas:

  • issue #48 Há legendas de formulários que podem não ser claras

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

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

    Verificámos que, no formulário “PROPOSTA DE ASSOCIADO”, disponível na página ASSOCIADOS, há rótulos como “Telf.”, “Telm.”, “Data Nascim.”, "NIF" ou "BI/CC" que podem não ser completamente claras para quem está a preencher.

    Uma solução mais acessível seria disponibilizar o formulário diretamente no site em vez de em formato PDF. Além disso, recomendamos que os rótulos sejam apresentados por extenso — por exemplo, “Telefone”, “Telemóvel”, “Data de Nascimento”. No caso de siglas, estas devem ser escritas por extenso (“NIF – Número de Identificação Fiscal”) ou acompanhadas do respetivo significado através do elemento <abbr>.

    Image

    Figura - Formulário “PROPOSTA DE ASSOCIADO”, disponível na página ASSOCIADOS.

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #50 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

    Os campos obrigatórios dos formulários devem estar devidamente identificados como tal. Idealmente, devem apresentar o texto “Obrigatório” à frente da legenda do campo. Pode-se colocar um * no campo obrigatório, desde que o significado do * seja mencionado no início do formulário.

    No formulário da página Contactos não existe informação sobre o significado do asterisco nos campos.

    Recomendamos a revisão dos formulários por forma a adicionarem uma legenda no início do formulário que indique claramente o significado de . Por exemplo, “ Campos de preenchimento obrigatório”.

    Adicionalmente, no caso dos formulários das páginas Voluntariado e Candidatura Espontânea – em que, à frente dos rótulos dos campos é usado “* (obrigatório)” – visto que não é fornecida uma informação clara sobre o significado do asterisco no formulário, recomendamos a que seja usado apenas “(obrigatório)” ou “(campo obrigatório)” à frente dos rótulos dos campos.

    Image

    Figura 1 - Formulário da página Contactos. Não existe informação sobre o significado do asterisco nos campos.

    Image

    Figura 2 - Formulário da página Candidatura Espontânea.

  • issue #49 Há campos obrigatórios que não estão identificados programaticamente

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

    O espaçamento entre linhas não é inferior a 1.5x o tamanho da letra.
    – ver requisito 2.4 na lista Conteúdo

    Verificámos que no formulário da página Contactos, os campos não estão identificados programaticamente como obrigatórios.

    Recomendamos que os campos obrigatórios incluam os atributos required ou aria-required=”true” para serem identificados pelas tecnologias de apoio como obrigatórios.

    Image

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

  • issue #47 Não é possível identificar campos obrigatórios nos ficheiros PDF

    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

    Verificámos que, no formulário “PROPOSTA DE ASSOCIADO”, disponível na página ASSOCIADOS, não é possível reconhecer os campos de preenchimento obrigatório. Esta informação não é passada quer visualmente quer para os leitores de ecrã.

    Uma solução mais acessível seria disponibilizar o formulário diretamente no site, em vez de em formato PDF. Nos formulários web, os campos obrigatórios devem incluir os atributos required ou aria-required=”true” para serem identificados pelas tecnologias de apoio como obrigatórios.

    Adicionalmente, deve ser apresentada uma indicação visual clara junto ao rótulo — por exemplo, “(Campo obrigatório)” — para que todos os utilizadores consigam identificar facilmente os campos que têm obrigatoriamente de preencher.

    Image

    Figura - Formulário “PROPOSTA DE ASSOCIADO”, disponível na página ASSOCIADOS onde não é possível reconhecer os campos de preenchimento obrigató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:

  • issue #17 Inexistência de ações longas

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

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

    Na análise realizada, não foram identificadas ações longas que exijam comunicação de estado ao utilizador.

    Desta forma, considera-se que o critério é não é aplicável.

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #82 Mensagem de sucesso oculta para tecnologias de apoio

    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

    Notas Gerais

    • Sempre que um utilizador realiza uma ação que implica o envio de informação, o sistema deve fornecer feedback adequado ao contexto linguístico.
    • A consistência do idioma nas mensagens de estado é crucial para garantir que o utilizador compreenda o feedback do sistema sem barreiras de idioma, mantendo a experiência inclusiva.

    URL a verificar

    Evidências:

    Nas páginas mencionadas, o atributo aria-hidden="true" está aplicado à div que contém a mensagem de sucesso “Obrigado pela sua mensagem”. Esta configuração torna a mensagem invisível para leitores de ecrã, impedindo que o utilizador com deficiência visual receba o feedback necessário.

    Image

    Figura 1 – Estrutura do código onde a mensagem de sucesso está marcada com aria-hidden="true"

    Recomendações:
    Remover o atributo aria-hidden="true" da div que contém a mensagem de sucesso.
    Garantir que a mensagem de sucesso seja injetada ou revelada de forma que um leitor de ecrã a anuncie automaticamente (preferencialmente utilizando role="status" ou aria-live="polite" no contentor da mensagem).

  • issue #16 Falta de tradução no feedback de processamento

    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

    Notas Gerais

    • Sempre que um utilizador realiza uma ação que implica o envio de informação, o sistema deve fornecer feedback adequado ao contexto linguístico.
    • A consistência do idioma nas mensagens de estado é crucial para garantir que o utilizador compreenda o feedback do sistema sem barreiras de idioma, mantendo a experiência inclusiva.

    URL a verificar

    Evidências:

    Durante a submissão do formulário, o rótulo do botão altera-se para “Sending”. Quando o utilizador navega na versão portuguesa do site, o feedback de processamento é apresentado em inglês, em vez de em português.

    Image

    Figura 1 – Feedback de processamento apresentado no botão em idioma não correspondente ao do site

    Recomendações:
    Atualizar o texto do botão de submissão para que o feedback de "envio em curso" seja apresentado no idioma da página (ex: "A enviar...").

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

etiqueta: N/A

Lista de evidências recolhidas:

  • issue #80 Não existem formulários que permitam ações destrutivas pelo utilizador

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

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

    Não identificamos formulários que permitem o utilizador fazer ações destrutivas e por esse motivo, consideramos esse critério como "Não aplicável".

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #68 Existem formulários com mensagens incompletas no topo

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

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

    As mensagens de erro apresentadas no topo do formulário SUGESTÕES, ELOGIOS E RECLAMAÇÕES estão incompletas e não remetem para os campos respetivos:

    Image

    Mensagens de erro no topo do formulário incompletas e sem remissão para os campos
    Neste momento não existe qualquer associação entre a mensagem no topo e os campos onde existem erros, pelo que esta mensagem não têm qualquer efeito positivo na perceção dos campos com erro de preenchimento.
    Recomendamos que as mensagens de erro apresentadas no topo de todos os formulários refiram os campos a que dizem respeito, para fornecer contexto ao utilizador que qual campo se refere cada mensagem.
    Recomendamos ainda que cada mensagem, ao ser clicada, remeta o foco para o respetivo campo (por exemplo, transformando cada mensagem num link cujo atributo href contenha o id de cada campo).
    Adicionalmente, solicitamos que questionem se faz sentido que a mensagem no topo seja apresentada apenas para as tecnologias de apoio.

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

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

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

    O formulário CONTACTOS não apresenta mensagens de erro junto aos campos:

    Image

    Campo email do formulário de contactos sem mensagem de erro associada
    As únicas mensagens de erro apresentadas ocorrem no fundo do formulário:

    Image

    Mensagem de erro no fundo do formulário
    As mensagens com a lista de erros devem ser apresentadas no topo e não no fundo dos formulários, e em formulários com número elevado de campos são de grande utilidade. Para além disso, devem ser apresentadas no mesmo idioma daquele configurado no site.
    Recomendamos que sejam apresentadas mensagens de erro junto aos campos de todos os formulários, para assim forenecerem apoio na correção dos mesmos e consequente submissão correta dos formulários.
    Adicionalmente, pode existir uma lista dos erros no topo de cada formulário que consolida os vários erros existentes, em que cada mensagem deve remeter para o respetivo campo (por exemplo, através da colocação da mensagem num link cujo href contenha o id do respetivo campo). Essa mensagem no topo deve estar no mesmo idioma do site.
    Recomendamos ainda que as mensagens de erro sejam programaticamente associadas aos respetivos campos, para que os utilizadores que navegam por teclado (tab e shift+tab) e leitor de ecrã possam ouvir a mensagem de erro associada a cada campo à medida que o foco passa pelos campos. A mensagem a associar programaticamente a cada campo deve ser a que se encontra junto do mesmo.
    A associação programática de uma mensagem de erro a um campo pode fazer-se adicionando dois atributos a esse campo:

    • Um atributo aria-invalid com o valor “true”, que indica que o campo não está num estado válido;
    • Um atributo aria-describedby com o id do elemento que contém a mensagem de erro. Em alternativa ao atributo aria-describedby pode ser utilizado um atributo aria-errormessage, também preenchido da mesma forma, com o id do elemento que contém a mensagem de erro.
      A diferença entre os dois atributos é que o atributo aria-errormessage foi desenhado mais recentemente e pode ainda não ser suportado por todas as tecnologias, e tem o propósito específico de fazer a associação programática entre um campo e a respetiva mensagem de erro, enquanto que o atributo aria-describedby é mais antigo e mais genérico, servindo em particular para fazer esta associação programática.
      Um exemplo de associação seria:
    <input type = "text" name = "email" aria-invalid = "true" aria-describedby = "msgerroremail">
<div id = "msgerroremail" class="popupMessage themeGreen">Email não válido</div>

  • issue #66 Existem mensagens de erro escondidas das tecnologias de apoio

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

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

    As mensagens de erro do formulário SUGESTÕES, ELOGIOS E RECLAMAÇÕES foram escondidas das tecnologias de apoio:

    Image

    Mensagens de erro escondidas das tecnologias de apoio através do atributo aria-hidden
    Conforme observado na figura, o span que contém a mensagem de erro associada ao não preenchimento do campo nome contém o atributo aria-hidden que oculta a mensagem de erro das tecnologias de apoio. Tal situação faz com que os utilizadores destas tecnologias fiquem impedidos de ver as mensagens de erro.
    Recomendamos a remoção do atributo aria-hidden de todas as mensagens de erro, de forma a que as mesmas estejam visíveis para todos os agentes.

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #78 Existem mensagens de erro que não ajudam na resolução do 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

    A mensagem de erro “Por favor digite um endereço de email” presente no formulário de contactos não ajuda no preenchimento do campo:

    Image

    Como observado na figura, a mensagem “Por favor digite um endereço de email” 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.

Outras violações

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

Lista de evidências recolhidas:

  • issue #88 Outras violações - Existem datepickers que permitem selecionar datas de nascimento no futuro

    etiqueta: melhoriaetiqueta: outras violações

    Verificámos que nas páginas Voluntariado e Candidatura Espontânea, no campo “Data de nascimento”, é possível selecionar uma data no futuro.

    Recomendamos que, neste campo, apenas seja possível selecionar uma data no passado. Por intermédio de JavaScript é possível definir as datas mínima e máxima que os utilizadores do datepicker podem escolher.

    Image

    Figura - Campo "Data de nascimento", no formulário da página Voluntariado, permite colocar datas futuras.

  • issue #84 Outras violações - Uso inadequado de overlays de acessibilidade

    etiqueta: melhoriaetiqueta: outras violações
    Descrição da problemática

    Os overlays de acessibilidade são frequentemente utilizados como soluções rápidas, mas não corrigem os problemas reais do website. Estas ferramentas funcionam como camadas sobrepostas ao código existente, sem resolver falhas estruturais como erros de semântica, foco, landmarks ou navegação por teclado.

    Em todo website, é utilizada a ferramenta "EA11y (Pojo Accessibility)" que em alguns casos, podem interferir com tecnologias de apoio (ex.: NVDA), criando comportamentos inesperados, atalhos redundantes ou problemas de apresentação, como textos cortados (Figura 1).

    Image

    Figura 1 - Textos cortados ao utilizar ferramenta overlays de acessibilidade

    Além disso, transmitem uma falsa perceção de conformidade, mantendo problemas de acessibilidade para utilizadores reais.

    Recomendação de melhoria
    Recomenda‑se que a acessibilidade seja assegurada prioritariamente através de boas práticas nativas: uso correto de HTML semântico, navegação por teclado funcional, contraste adequado e compatibilidade com tecnologias de apoio. Os overlays não devem substituir a correção estrutural do site, pois a melhoria da acessibilidade deve começar na base do código e não depender exclusivamente de ferramentas externas. Sendo assim, devem ser removidos do website.

  • issue #74 Outras violações - Botão "Saltar para o conteúdo" não funciona

    etiqueta: melhoriaetiqueta: outras violações
    Descrição do problema

    O botão “Saltar para o conteúdo” não está a funcionar corretamente ao ser ativado com teclado (Enter) e leitores de ecrã como NVDA.

    Atualmente, ao acionar o link, não ocorre qualquer deslocamento (scroll) nem mudança de foco para o conteúdo principal, o que impede a navegação eficiente por teclado e compromete a acessibilidade. O comportamento esperado é que o foco seja movido diretamente para a área principal da página ao ativar o link. (Figura 1)

    Image

    Figura 1- Botão "Saltar para o conteúdo" não funciona

    Este problema acontece, pois não existe um verdadeiro elemento <main> semântico a representar o conteúdo principal da página. Apesar da existência de um elemento com o identificador #main, este não se encontra no contentor estrutural correto, o que compromete a sua função enquanto região principal. Adicionalmente, o layout recorre a múltiplos <divs> que interferem com o comportamento do scroll por âncora, fazendo com que links internos (como “saltar para o conteúdo”) não posicionem corretamente o foco nem a visualização do conteúdo de destino. Este problema afeta diretamente utilizadores que dependem de navegação por teclado e tecnologias assistivas.

    Recomendações
    Rever a estrutura do website, e criar um elemento <main> semântico único e corretamente posicionado, representando de forma clara o conteúdo principal da página, assegurando que o botão "Saltar para o conteúdo" funcione corretamente.

  • issue #70 Outras violações - O website não utiliza landmarks de forma apropriada

    etiqueta: melhoriaetiqueta: outras violações
    Descrição da problemática

    O website apresenta falhas ao nível da utilização de landmarks semânticos, que são essenciais para uma navegação acessível, nomeadamente para utilizadores de leitores de ecrã.

    Alguns elementos interativos globais, como o botão de “voltar ao topo” e o botão de "Translate", encontram-se fora de qualquer landmark (header, nav, main, footer, etc.), estando inseridos em <div> genéricas. Esta abordagem faz com que estes controlos não sejam corretamente identificados por tecnologias de apoio, dificultando a sua descoberta e utilização. (Figura 1)

    Image

    Figura 2 - Leitor de ecrã identifica apenas header e navegação principal

    Adicionalmente, o website não possui um landmark <footer> devidamente definido. O conteúdo que funciona visualmente como rodapé está inserido dentro de uma <div> localizada no interior do <main>. Esta estrutura é semanticamente incorreta, uma vez que o <main> deve conter apenas o conteúdo principal da página e o

    deve existir como uma região independente. A implementação atual, impacta diretamente na navegação por landmarks através de leitores de ecrã, que não reconhecem a existência de um <footer> presente na página (Figura 2)

    Image

    Figura 2 - Leitor de ecrã identifica apenas header e navegação principal

    Estas situações comprometem a compreensão da estrutura da página, dificultam a navegação por regiões e afetam negativamente a experiência de utilizadores com tecnologias de apoio.

    Recomendações de Melhoria
    Recomenda‑se a reorganização da estrutura da página, utilizando corretamente os elementos semânticos HTML5.
    Os botões globais, como o botão de tradução, devem estar no idioma do website e ser integrados no <header> ou num <nav> apropriado, com identificação clara da sua função. O botão de “voltar ao topo” deve estar incluído dentro de um landmark relevante, como o <main>, garantindo que não fica solto na estrutura do documento.
    É igualmente recomendada a criação de um elemento <footer> semântico, colocado fora do <main>, que contenha toda a informação de rodapé do website. O uso de <div> deve ser limitado a situações em que não exista um elemento semântico mais adequado.

  • issue #46 Outras violações - Há elementos que apresentam-se sobrepostos e dificultam a legibilidade

    etiqueta: melhoriaetiqueta: outras violações

    Descrição do problema

    • Alguns elementos do website apresentam-se sobrepostos, o que dificulta a legibilidade do conteúdo e a distinção entre informação e elementos interativos, podendo comprometer a compreensão e a usabilidade da página.

    Ponto 01

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

    Ao aceder à página inicial, o pop-up da campanha possui um texto em inglês com a mensagem “This will close in 10 seconds”, sendo assim, o texto informa que o pop-up será fechado em segundos. No entanto, o texto pode não ser percetível para todos utilizadores pois apresenta-se sobrepondo a janela e parcialmente cortado, comprometendo a legibilidade da informação.
(Figura 1)

    Image

    Figura 1 - Texto não visível que informa sobre fechamento automático da modal

    Recomendação

    Assegurar que a mensagem de aviso está no idioma do website e que se mantém visível, legível e sem cortes.

    Ponto 02
    Página: https://appacdmviseu.pt/projetos/banco-de-tecnologias-de-apoio/comunicacao/

    Nos carrosséis de imagens, as setas de navegação (anterior/seguinte) encontram-se sobrepostas ao conteúdo visual dos slides, interferindo diretamente na perceção das imagens. (Figura 2)

    Image

    Figura 2 - Controlos do carrossel sobrepõem imagens

    Esta sobreposição pode dificultar a legibilidade, gerar confusão entre conteúdo e controlos interativos e comprometer a compreensão da informação apresentada, sobretudo para utilizadores com baixa visão ou dificuldades cognitivas.

    Recomendação de melhoria
    Recomenda-se reposicionar as setas fora da área das imagens ou aplicar um fundo opaco e contraste adequado aos controlos de navegação, garantindo uma distinção visual clara entre conteúdo e elementos interativos

Significado das etiquetas utilizadas