Relatório Avaliação de Candidatura
Portal Institucional do Município de Oeiras

Introdução

O website https://www.oeiras.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 aspetos29.6% (8/27)etiqueta: Não passa
Conteúdo0.0% (0/17)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: 29.6% (8/27)
    • Requisitos avaliados: 27 (27 aplicáveis)
    • Requisitos OK: 8
    • Requisitos NOK: 19

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 #52 O menu do rodapé não está estruturado como uma lista

    etiqueta: chk 10 webetiqueta: R 1.1etiqueta: NOK

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

    Evidencias:

    Apesar de estarem a utilizar a semântica de lista com ul e li, foi utilizado atributos como o role="menubar" e role="presentation" que alteram a semântica nativa desses elementos. Como consequência, as tecnologias de apoio deixam de os reconhecer como uma lista, passando a interpretá‑los como componentes de menu:

    Image

    Opções do menu rodapé com os atributos role="menubar" e role="presentation"

    Image

    Imagem da navegação com teclado saltando a lista do rodapé.

    URL's a verificar:

    Recomendações:

    • Remover os atributos role="menubar" e role="presentation" do menu do rodapé.

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 #53 O menu não está construído de forma apropriada

    etiqueta: chk 10 webetiqueta: NOKetiqueta: R 1.2

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

    Evidencias:

    Quando navegamos pelo menu principal utilizando o rato, teclado e leitor de ecrã é possível identificar os seguintes erros:

    • Não é possível percorrer pelas subopções sem antes percorrer pelas opções do primeiro nível.
    Image

    Imagem da navegação do teclado tendo que passar por todas as opções do "Viver" para poder aceder ao "Descobrir".

    • Não é possível abrir as subopções a partir da opção principal. Por exemplo, para aceder às subopções de “Investir”, o utilizador é obrigado a abrir o menu completo, uma vez que não existe forma de expandir as subopções a partir da própria opção “Investir”.
    Image

    Imagem do utilizador precisando abrir o menu completo para acessar as opções de "Investir".

    URL's a verificar:

    Recomendações:

    • É necessário alterar a construção do menu e como as subopções estão sendo apresentadas. Para isso, cada opção do menu ( viver, descobrir, investir, serviços e município) deve ser acompanhado por um botão (▾) que permita visualizar as suas respectivas subopções. O botão deve ter um nome acessível, como por exemplo, "Abrir subopções de viver".
    • Partilhamos um exemplo de construção do menu que pode ajudar: https://www.w3.org/WAI/tutorials/menus/flyout/#use-button-as-toggle

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 #55 O menu mobile está com texto alternativo inapropriado

    etiqueta: chk 10 webetiqueta: melhoriaetiqueta: R 1.3

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

    Evidencias:

    O botão mobile de fechar o menu têm p texto alternativo "Sair" o que não indica corretamente a ação que o botão vai realizar, podendo gerar dúvidas:

    Image

    Imagem do menu para fechar sem qualquer label

    URL's a verificar:

    Recomendações:

    • Alterar o nome acessível do botão como "Fechar".

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #41 Existência de multiplos h1 na página web

    etiqueta: chk 10 webetiqueta: R 2.1etiqueta: NOK

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

    Evidencias:

    Cada página do website deve conter um único elemento <h1>, que represente o título principal do conteúdo. A utilização de múltiplos <h1> pode comprometer a interpretação da hierarquia da página por tecnologias de apoio.

    Na página de Declaração de Acessibilidade, verifica-se a existência de dois elementos <h1>, o que constitui uma utilização incorreta da estrutura de cabeçalhos.

    Esta duplicação poderá gerar problemas caso ambos os cabeçalhos h1 fiquem visíveis para os leitores de ecrã.

    Image

    Figura 1 - Identificação de dois cabeçalhos marcados com <h1> na mesma página. .

    URLs a verificar:

    Recomendações:

    • Remover o título genérico "Navegação" da página de Declaração de Acessibilidade e Usabilidade.

  • issue #40 Cabeçalho h1 genérico em todas as páginas

    etiqueta: chk 10 webetiqueta: R 2.1etiqueta: NOK

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

    Evidências

    Actualmente, todas as páginas apresentam o mesmo <h1> ("Navegação"). O elemento <h1> deve ser atribuído ao título principal de cada página de forma a identificar de forma clara o respetivo conteúdo.

    Image

    Figura 1 - Exemplo do <h1> estar igual em todas as páginas .

    URLs a verificar:

    Verificar todas as páginas do website.

    Recomendações

    • Remover o <h1> "Navegação" de todas as páginas.
    • Garantir que existe um único elemento h1, correspondente ao título principal de cada página.
    • Em todas as páginas o título principal está a ser atribuído como h2 sendo necessário alterar para h1. Devem garantir que essa alteração não gere problemas na hierarquia entre os cabeçalhos.

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

etiqueta: NOK

Lista de evidências recolhidas:

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #43 Elemento th em falta nos cabeçalhos da tabela

    etiqueta: chk 10 webetiqueta: NOKetiqueta: R 3.1

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

    Evidencias:

    Na página analisada, foi identificada uma estrutura marcada como tabela que não apresenta dados tabulares nem relações entre linhas e colunas que justifiquem a utilização deste elemento.

    O conteúdo consiste essencialmente em informação organizada por datas, funcionando mais como secções de conteúdo do que como dados tabulares.

    Nestas circunstâncias, a utilização de uma tabela pode induzir em erro os utilizadores de tecnologias de apoio, que esperam encontrar relações entre cabeçalhos e células de dados.

    Image

    Figura 1 - Conteúdo apresentado através de uma tabela, embora não represente dados tabulares .

    URLs a verificar:

    Recomendações:

    • Remover a estrutura de tabela utilizada para apresentar este conteúdo.
    • Estruturar as datas como cabeçalhos semanticamente adequados, respeitando a hierarquia de cabeçalhos da página.
    • Utilizar elementos HTML apropriados para representar listas, secções ou agrupamentos de conteúdo, em vez de tabelas quando não existem relações tabulares entre os dados apresentados.

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #57 Elemento caption em falta na legenda da tabela

    etiqueta: chk 10 webetiqueta: NOKetiqueta: R 3.2

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

    Evidencias:

    Na página analisada, foi identificada uma estrutura marcada como tabela que não apresenta dados tabulares nem relações entre linhas e colunas que justifiquem a utilização deste elemento.

    O conteúdo encontra-se organizado por datas e secções informativas, funcionando como conteúdo estruturado da página e não como uma tabela de dados.

    Nestas circunstâncias, a utilização de uma tabela não é semanticamente adequada e pode dificultar a interpretação do conteúdo por utilizadores de tecnologias de apoio.

    Image

    Figura 1 - Conteúdo apresentado através de uma tabela, embora não represente dados tabulares .

    URLs a verificar:

    Recomendações:

    • Remover a estrutura de tabela utilizada para apresentar este conteúdo.
    • Estruturar as datas como cabeçalhos semanticamente adequados, respeitando a hierarquia de cabeçalhos da página.
    • Utilizar elementos HTML apropriados para representar secções, listas ou agrupamentos de conteúdo.
    • Reservar a utilização de tabelas exclusivamente para a apresentação de dados tabulares com relações entre linhas e colunas.

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 #59 Campos de filtro da Agenda com labels não visíveis

    etiqueta: chk 10 webetiqueta: NOKetiqueta: R 4.1

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

    Evidencias:
    Na página da Agenda foram identificados campos de filtragem (“tema” e “localização”) com elementos <label> corretamente associados aos respetivos controlos <select> através de for e id, mas as etiquetas encontram-se ocultas visualmente através da classe sr-only.

    Embora exista associação programática entre as labels e os respetivos campos, a identificação visual dos controlos depende exclusivamente da primeira opção do seletor (“tema” e “localização”), funcionando como substituto visual da etiqueta.

    Este comportamento pode gerar ambiguidades na utilização, especialmente após seleção de um valor, uma vez que a função do campo deixa de estar claramente identificada no ecrã.

    A ocultação visual das labels reduz ainda a área clicável associada ao campo, impedindo que o utilizador possa focar o seletor ao clicar sobre uma etiqueta visível, o que pode dificultar a interação para pessoas com limitações motoras.

    Image

    Figura 1 - Campos de filtro da Agenda com labels ocultas visualmente e dependência da option inicial para identificação

    URLs a verificar:

    Recomendações:

    • Garantir que as labels dos filtros permanecem visíveis no ecrã, mantendo simultaneamente a associação programática através de for e id
    • Evitar utilizar a primeira opção do <select> como substituto visual da etiqueta do campo
    • Garantir que a identificação funcional dos filtros permanece persistente, mesmo após seleção de um valor
    • Manter consistência entre identificação visual e programática dos controlos de formulário

  • issue #30 Campo de pesquisa com ausência de etiqueta acessível e dependência de placeholder

    etiqueta: chk 10 webetiqueta: NOKetiqueta: R 4.1

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

    Evidencias:

    No código analisado referente ao campo de pesquisa do cabeçalho, verifica-se a ausência de um elemento <label> associado ao campo de pesquisa através de for e id.

    O campo apresenta apenas os seguintes mecanismos de identificação:

    • placeholder="Search...", utilizado como principal elemento identificador visual
    • title="Pesquisar", que não garante um nome acessível consistente em tecnologias de apoio
    • Ausência de associação programática entre uma etiqueta e o input

    Adicionalmente, o placeholder não constitui uma etiqueta acessível, uma vez que desaparece durante a interação do utilizador, deixando de fornecer contexto funcional sobre o campo de pesquisa.

    Image

    Figura 1 - Campo de pesquisa no cabeçalho sem etiqueta acessível associada

    URLs a verificar:

    Recomendações:
    Recomenda-se garantir que o campo de pesquisa possui um nome acessível corretamente definido, através da seguinte abordagem:

    • Implementação de um elemento <label> associado ao input através de for e id

    Adicionalmente, recomenda-se:

    • Evitar utilizar o placeholder como substituto de etiqueta, sendo este apenas um elemento de apoio ao preenchimento
    • Garantir que o campo mantém sempre um nome acessível persistente, independentemente do estado de interação
    • Assegurar consistência entre identificação visual e programática do controlo

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

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

Lista de evidências recolhidas:

  • issue #51 Identificação de campos obrigatórios em formulários

    etiqueta: chk 10 webetiqueta: melhoriaetiqueta: R 4.2

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

    – ver requisito 4.2 na lista 10 aspetos

    Evidências:

    Foi identificado um campo de formulário com indicação de obrigatoriedade representada apenas por um símbolo visual (*), incluído dentro do <label>.

    Este indicador não fornece informação estruturada ou programática suficiente para tecnologias de apoio.

    Não foi identificado no input qualquer reforço semântico da obrigatoriedade (ex.: required ou aria-required="true").

    Image

    Figura 1 - Campo com indicação de obrigatoriedade apenas visual (*)

    URLs a verificar:

    Recomendações:
    Recomenda-se garantir que a obrigatoriedade dos campos é corretamente comunicada tanto visualmente como programaticamente.

    Podem ser adotadas uma das seguintes abordagens:

    • Utilizar indicação textual explícita, como “campo obrigatório”, associada ao respetivo campo;
    • Utilizar o símbolo * para assinalar campos obrigatórios, desde que seja apresentada no topo do formulário uma indicação clara de que * significa “campo de preenchimento obrigatório”.

    Os campos obrigatórios devem utilizar o atributo required, permitindo que a obrigatoriedade seja corretamente identificada por tecnologias de apoio.

    Caso sejam utilizados simultaneamente o símbolo * e uma indicação textual acessível (ex.: “campo obrigatório” oculto visualmente), deve ser evitada redundância para leitores de ecrã, ocultando o símbolo * às tecnologias de apoio (aria-hidden="true").

    Deve ainda evitar-se que a identificação da obrigatoriedade dependa exclusivamente de elementos visuais sem explicação contextual.

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

    etiqueta: chk 10 webetiqueta: melhoriaetiqueta: R 4.2

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

    Evidências

    Os campos obrigatórios de formulário 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.

    Verificámos que no formulário da Subscrição da Newsletter não existe informação sobre o significado do asterisco (*) colocado à frente dos campos.

    Image

    Figura 1 - Formulário da página de Subscrição da Newsletter. Não existe informação sobre o significado do asterisco (*) colocado à frente dos campos.

    URLs a verificar

    Recomendações

    Recomendamos a revisão dos formulários de forma a ser adicionada uma legenda no início do formulário a indicar claramente o significado de *.

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

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

Lista de evidências recolhidas:

  • issue #56 Feedback de erro inconsistente e não acessível em formulário

    etiqueta: chk 10 webetiqueta: melhoriaetiqueta: R 4.3

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

    Evidências:

    No formulário de subscrição da newsletter foram identificadas inconsistências na apresentação e comunicação de erros de validação dos campos.

    Após submissão do formulário sem preenchimento dos campos obrigatórios, observa-se que:

    • O campo “Endereço de email” apresenta uma mensagem de erro (“Por favor digite um valor”), mas esta não é visualmente percecionável, aparentando existir um problema de apresentação/contraste, resultando apenas numa alteração visual do estado do campo
    • O campo “Nome”, também obrigatório, não apresenta qualquer feedback de erro visível
    • Existe uma mensagem genérica no topo (“There are errors below”), mas sem identificação clara dos campos afetados e invisível
    • As mensagens de erro não são consistentes entre campos obrigatórios equivalentes
    • O estado de erro depende predominantemente de formatação visual (cor vermelha), o que pode não ser suficiente para utilizadores com limitações visuais ou leitores de ecrã

    Como consequência, os utilizadores podem ter dificuldade em compreender quais os campos com erro e que ações devem executar para corrigir o formulário, particularmente quando utilizam tecnologias de apoio.

    Image

    Figura 1 - Feedback de erro inconsistente entre campos obrigatórios do formulário

    URLs a verificar

    Recomendações:

    • Garantir feedback de erro consistente para todos os campos obrigatórios;
    • Apresentar mensagens de erro claras e coerentes com o erro efetivamente identificado;
    • Garantir que as mensagens de erro são atualizadas ou removidas quando o estado do campo é corrigido;
    • Não depender exclusivamente de alterações visuais (ex.: cor) para comunicar erros;
    • Opcionalmente, incluir um resumo de erros no topo do formulário com indicação clara dos campos afetados.

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.3 - As imagens-link têm um equivalente alternativo correto

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #20 Nome acessível pouco descritivo em botões de navegação temporal

    etiqueta: chk 10 webetiqueta: melhoriaetiqueta: R 5.3

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

    Evidências:

    No componente de navegação temporal, foram identificados botões de navegação representados por ícones de setas, responsáveis por alterar o período apresentado (ex.: mês, semana, dia ou ano).

    Exemplo:

    <button aria-label="left arrow" class="selectTimeElement">...</button>
<button aria-label="Arrow Right" class="selectTimeElement">...</button>

    Os nomes acessíveis atuais descrevem apenas a direção visual do ícone, não identificando a ação executada pelo controlo.

    Adicionalmente, o comportamento do botão depende do modo de visualização selecionado (ano, mês, semana ou dia).

    Image

    Figura 2 - Botões de navegação temporal com aria-label descritivo da direção (“left arrow” / “Arrow Right”) em vez da ação

    URLs a verificar:

    Recomendações:

    Recomenda-se que os nomes acessíveis dos botões descrevam a ação executada em vez da forma visual do ícone.

    Sugestões:

    • “Período anterior” / “Período seguinte”, ou
    • “Ano anterior/seguinte”, “Mês anterior/seguinte”, etc., de forma dinâmica conforme o modo ativo.

    Deve ainda ser garantida consistência de idioma na interface, utilizando português em todos os aria-label.

  • issue #7 Imagem link têm um equivalente alternativo incorreto

    etiqueta: chk 10 webetiqueta: NOKetiqueta: R 5.3

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

    Evidências:

    Verifica-se que a imagem apresentada como ligação possui um nome acessível incorreto. Ao navegar com o leitor de ecrã, a imagem-link é anunciada como “link, imagem, ebbdb0d5-5d26-e1ed-3a22-faff3bb50b37”, ou seja, é lido um identificador técnico/automático em vez de uma descrição compreensível sobre o conteúdo ou destino da ligação.

    Como se trata de uma imagem-link, o nome acessível deve indicar claramente a finalidade da ligação ou o conteúdo representado pela imagem. Por exemplo: alt=“Regras de segurança em espaços públicos”.

    Image

    Verifica-se que a imagem-link do logótipo utilizada como link para a página inicial possui atributo title para fornecer o seu nome acessível. Nesse caso o atributo title deve ser removido e o equivalente alternativo deve ser disponibilizado no mecanismo acessível principal através do alt na imagem. Por exemplo: alt="Câmara Municipal de Oeiras - página inicial"

    Image

    Verifica-se que as imagens-link das redes sociais estão a depender exclusivamente do atributo title para fornecer o seu nome acessível. Nesse caso o equivalente alternativo deve ser disponibilizado no mecanismo acessível principal através do aria-label. Por exemplo: aria-label="Visite o nosso Twitter". O title deve ser removido.

    Image
    • Imagem-link da galeria

    Verifica-se que as imagens da galeria não estão diretamente acessíveis às tecnologias de apoio o único elemento acessível é o botão de ampliação apresentado sobre a imagem. No entanto, este botão deve possuir um nome acessível claro, indicando a ação e o conteúdo associado, para que o utilizador compreenda qual imagem será ampliada ao ativá-lo.

    Image
    • Imagem ampliada da galeria
      A imagem ampliada deve apresentar um texto alternativo que descreva claramente o conteúdo da imagem, garantindo consistência na identificação do conteúdo visual.
    Image

    Verifica-se que os ícones de login, alertas e pesquisar não apresentam um equivalente alternativo textual que represente fielmente o destino ou a ação da hiperligação. A acessibilidade da hiperligação deve ser garantida através de um nome acessível claro no elemento <a>, como por exemplo: aria-label="Iniciar sessão" ou texto acessível equivalente. Isso acontece também com o ícone de pesquisa e a sinalização.

    Image

    URL:

    Recomendações:

    • O texto alternativo deve transmitir claramente o destino ou finalidade do link.
    • As imagens-link deverão ter uma descrição breve associada, nomeadamente através do uso do atributo alt descrevendo corretamente a imagem apresentada, sem identificadores técnicos ou caracteres desnecessários.
    • Quando o link direciona para um novo separador esta informação deve ser comunicada ao utilizador através do nome acessível da imagem.
    • O elemento <a> que envolve o SVG deve ter um nome acessível e descritivo através de aria-label.

    Nas imagens da Galeria:

    • Recomenda-se garantir que as imagens da galeria e respetivos controlos sejam corretamente identificados pelas tecnologias de apoio. Como o elemento acessível antes da abertura é o botão de ampliação, este deve ter um nome acessível claro, indicando a ação e a imagem associada, por exemplo: aria-label="Ampliar imagem da garrafa e embalagem do Vinho Villa Oeiras".

    • Após a ampliação, a imagem apresentada no modal também deve possuir texto alternativo adequado, descrevendo o conteúdo visual relevante, por exemplo: alt="Garrafa e embalagem do Vinho Villa Oeiras".

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 #28 Texto normal não tem contraste suficiente

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

    Evidências

    • 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 a ferramenta Colour Contrast Analyser revela problemas relacionados com insuficiência de contraste, afetando diretamente a legibilidade.

    O website apresenta problemas de contraste, por exemplo na combinação de cores #1DC2F3(cor de primeiro plano) e #FFFFFF(cor de plano de fundo) que torna os textos pouco visíveis. (Figura 1)

    Image

    Figura 1- Texto normal “Próximo” com problemas de contraste na página Boletim Municipal

    Image

    Figura 2 - Problemas de contraste em textos normais da página Festas de Oeiras 2026

    URLs a verificar

    Recomendações
    Recomendamos a revisão das combinações de cores das páginas de todo website para garantir os valores mínimos de contraste do texto grande. Garantir consistência nos estados visuais (normal, hover, foco) com contraste adequado;

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 #29 Texto grande não têm contraste suficiente em certos estados

    etiqueta: chk 10 webetiqueta: NOKetiqueta: R 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.
    – ver requisito 6.2 na lista 10 aspetos

    Evidências

    • O contraste no texto grande (superior a 18 pontos ou superior a 14 pontos negrito) das páginas deve ser, no mínimo 3:1, para que as pessoas com baixa visão consigam ler o texto.

    A avaliação com a ferramenta Colour Contrast Analyser revela problemas relacionados com insuficiência de contraste, afetando diretamente a legibilidade.

    O website apresenta problemas de contraste no texto grande, nas opções de primeiro nível do menu ao navegar com o teclado com TAB as opções “Viver”, “Descobrir”, “Investir”, “Serviços” e “Município” pois utilizam a combinação de cores #0080a3(cor de primeiro plano) e #006783(cor de plano de fundo). (Figura 1 e 2)

    Image

    Figura 1 - Títulos grandes do menu com problemas de contraste

    Image

    Figura 2 - Avaliação de contraste para componentes pela navegação por teclado

    Image

    Figura 3 - Problemas de contraste em textos grandes da página Festas de Oeiras 2026

    O mesmo problema ocorre na navegação por teclado na componente de acordeões utilizada em páginas internas do website. Por exemplo, na página Estratégia e Economia, na secção “Projetos estratégicos para Oeiras!”, verifica-se a utilização da mesma cor (#0080a3) tanto para o primeiro plano (texto) quanto para o plano de fundo. Esta prática compromete o contraste e torna o texto invisível quando o foco é aplicado através da tecla TAB. (Figura 4)

    Image

    Figura 4 - Problemas de contraste na navegação por teclado por textos em listas e links dos acordeões

    URLs a verificar

    Recomendações
    Recomendamos a revisão das combinações de cores das páginas para garantir os valores mínimos de contraste do texto grande. Garantir consistência nos estados visuais (normal, hover, foco) com contraste adequado;

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.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 #58 Estrutura semântica incorreta na navegação de salto para conteúdo

    etiqueta: chk 10 webetiqueta: R 8.3etiqueta: NOK

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

    Evidências:

    Na página inicial foi identificada uma região de navegação (<nav>) denominada “Links Rápidos”, composta apenas por um único link de salto para o conteúdo principal (“Passar para o Conteúdo”).

    Adicionalmente, esta estrutura inclui um elemento <h1> oculto visualmente

    Foram identificados os seguintes problemas:

    • O elemento <nav> aparenta estar a ser utilizado para agrupar apenas um mecanismo de salto para conteúdo (“skip link”), não correspondendo a uma verdadeira região de navegação do website
    • A existência de uma landmark de navegação adicional pode introduzir ruído desnecessário para utilizadores de leitores de ecrã, dificultando a compreensão da estrutura da página
    • O elemento <h1> oculto (“Navegação”) é semanticamente inadequado neste contexto, podendo ser anunciado como cabeçalho principal da página pelas tecnologias de apoio
    • A utilização deste cabeçalho pode interferir com a hierarquia de headings e dificultar a navegação por estrutura semântica

    Como consequência, utilizadores de leitores de ecrã poderão encontrar landmarks redundantes e cabeçalhos sem significado estrutural real, comprometendo a compreensão da organização da página.

    Image

    Figura 1 - Região de “Links Rápidos” implementada como <nav> com heading <h1> inadequado

    URLs a verificar:

    Recomendações:

    • Remover a utilização do elemento <nav> quando exista apenas um mecanismo de salto para conteúdo
    • Implementar o link “Passar para o Conteúdo” diretamente na página, sem criar uma landmark de navegação adicional desnecessária
    • Remover o elemento <h1> associado a esta funcionalidade
    • Garantir que a hierarquia de headings da página representa apenas conteúdos estruturais reais
    • Validar com leitores de ecrã para confirmar que a navegação por landmarks e cabeçalhos permanece clara e sem redundância

  • issue #49 Breadcrumb sem estrutura semântica adequada

    etiqueta: chk 10 webetiqueta: R 8.3etiqueta: NOK

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

    Evidências

    Verificou-se que o componente de navegação contextual (breadcrumb) não se encontra estruturado semanticamente de forma adequada.

    Atualmente, o breadcrumb é implementado através de elementos <a> agrupados num elemento genérico <div>, sem utilização de uma estrutura de lista ordenada (<ol> / <li>) nem de uma região de navegação identificável.

    Os breadcrumbs representam uma sequência hierárquica de navegação e devem ser interpretados programaticamente como uma lista ordenada de localizações dentro do website.

    Na implementação atual, tecnologias de apoio podem não conseguir identificar corretamente a relação hierárquica entre os elementos, dificultando a compreensão da localização atual do utilizador no website, especialmente quando os estilos CSS são removidos.

    Verificou-se ainda a ausência de identificação programática da página atual através do atributo aria-current="page".

    Image

    Figura 1 - Breadcrumb implementado com elementos genéricos (<div> e <a>) sem estrutura semântica de navegação ordenada

    URLs a verificar

    Recomendações

    • Estruturar semanticamente o breadcrumb através de uma região de navegação (<nav>) com nome acessível apropriado, por exemploaria-label="Caminho de Navegação".
    • Utilizar uma lista ordenada (<ol>) para representar a hierarquia de navegação, com cada elemento inserido num <li>
    • Identificar programaticamente a página atual através de aria-current="page"
    • Evitar a utilização exclusiva de elementos genéricos (<div>) para representar relações hierárquicas de navegação
    • Validar o comportamento com tecnologias de apoio para garantir correta interpretação da estrutura e localização atual do utilizador no website

  • issue #48 Controlos do banner de cookies implementados com semântica incorreta

    etiqueta: chk 10 webetiqueta: R 8.3etiqueta: NOK

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

    Evidências:

    Verificou-se que os controlos do banner de cookies (“Aceito”, “Rejeitar” e “Configuração”) encontram-se implementados através de elementos <a> sem atributo href, apesar de desempenharem ações da interface e não navegação para outro recurso.

    Atualmente, estes elementos executam operações funcionais (aceitar, rejeitar ou configurar cookies), pelo que semanticamente deveriam ser implementados como elementos <button>.

    A utilização de âncoras (<a>) neste contexto pode levar tecnologias de apoio a anunciar incorretamente estes controlos como “hiperligações”, quando na realidade se tratam de ações interativas da interface.

    Adicionalmente, a ausência do atributo href faz com que estes elementos não beneficiem integralmente do comportamento nativo esperado de links nem da semântica correta de botões.

    Image

    Figura 1 - Controlos do banner de cookies implementados como elementos em vez de botões semânticos (<button>)

    URLs a verificar:

    Recomendações:

    • Substituir os elementos <a> utilizados para ações da interface por elementos <button type="button">
    • Reservar o elemento <a> exclusivamente para navegação entre páginas, secções ou recursos
    • Garantir que os controlos são anunciados corretamente por tecnologias de apoio como “botão”
    • Validar a interação através de teclado e leitores de ecrã para confirmar a correta semântica e comportamento dos controlos

  • issue #33 Ausência de região principal semântica (`<main>`) na estrutura da página

    etiqueta: chk 10 webetiqueta: R 8.3etiqueta: NOK

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

    Evidências:

    Observa-se que a página não possui uma região principal claramente identificada como conteúdo principal através do elemento semântico <main> ou de um equivalente com role="main".

    Embora exista uma estrutura organizada através do elemento <section class="marginMainSection" id="content">, esta não está semanticamente identificada como região principal da página.

    Esta ausência impede que tecnologias de apoio, como leitores de ecrã, identifiquem de forma direta e consistente o conteúdo principal da página, dificultando a navegação por regiões e a compreensão da hierarquia estrutural.

    Image

    Figura 1 - Estrutura da página sem identificação explícita de região principal (<main> ou equivalente)

    URLs a verificar:

    Recomendações:

    • Implementar um elemento semântico <main> para envolver o conteúdo principal da página
    • Garantir a existência de apenas um <main> por página
    • Caso não seja possível utilizar <main>, aplicar role="main" ao elemento que contém o conteúdo principal
    • Validar a estrutura com ferramentas de acessibilidade e leitores de ecrã para garantir identificação correta das regiões da página

    Referência: MDN – ARIA landmark roles

  • issue #18 Falta de identificação programática do estado selecionado nos controlos de seleção

    etiqueta: chk 10 webetiqueta: R 8.3etiqueta: NOK

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

    Evidências:

    No componente de seleção de período (ano, mês, semana, dia), os botões são apresentados como elementos interativos do tipo <button>, sendo utilizado um estilo visual para indicar o estado selecionado através da classe selected.

    Contudo, o estado ativo do controlo não é expresso programaticamente através de atributos ARIA, como aria-selected ou aria-pressed.

    Como consequência, utilizadores de tecnologias de apoio podem não conseguir identificar qual o período atualmente selecionado, dependendo apenas da estilização visual.

    Image

    Figura 1 - Botões de seleção de período (ano, mês, semana, dia) com estado ativo definido apenas por classe CSS

    URLs a verificar:

    Recomendações:

    Recomenda-se a implementação de um mecanismo acessível para indicação do estado selecionado, por exemplo:

    • utilização de aria-selected="true" (caso seja estruturado como tabs);
    • ou aria-pressed="true" (caso seja estruturado como botões de alternância);

    assegurando que o estado ativo do controlo é corretamente comunicado a tecnologias de apoio.

  • issue #15 Identificação pouco clara da opção inicial dos filtros de seleção

    etiqueta: chk 10 webetiqueta: R 8.3etiqueta: melhoria

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

    Evidências:

    Nos filtros do calendário/eventos, verificámos que os campos de seleção apresentam como primeira opção os textos “tema” e “localização”.

    Embora os controlos possuam etiquetas corretamente associadas programaticamente, a opção inicial apresentada no <select> pode gerar ambiguidade relativamente ao comportamento do filtro, não sendo claro se representa:

    • uma instrução de utilização;
    • um valor selecionado;
    • ou a ausência de filtragem.

    Atualmente, a primeira opção corresponde a:

    • “tema”
    • “localização”

    Contudo, o comportamento associado aparenta corresponder à apresentação de todos os resultados, isto é, sem aplicação de filtro.

    Image

    Figura 1 - Opções iniciais dos filtros apresentadas com identificação ambígua (“tema” e “localização”)

    URLs a verificar:

    Recomendações:

    Recomenda-se a revisão do texto apresentado na opção inicial dos filtros, de forma a refletir explicitamente o comportamento do controlo.

    Por exemplo:

    • “Todos os temas” em vez de “tema”
    • “Todas as localizações” em vez de “localização”

    Desta forma, torna-se mais claro para todos os utilizadores que a opção corresponde à ausência de filtragem e à apresentação global dos resultados.

  • issue #12 Duplicação de links para o mesmo conteúdo

    etiqueta: chk 10 webetiqueta: R 8.3etiqueta: NOK

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

    Evidências:
    Em cada item da listagem, observa-se a existência de dois elementos clicáveis (<a>) com o mesmo destino:

    • Um elemento <a> associado à imagem da notícia;
    • Um segundo elemento <a> separado, associado ao título e data da notícia, ambos a apontar para o mesmo destino.

    Ambos apontam para a mesma página, resultando em redundância de navegação e aumento do número de elementos interativos.

    Image

    Figura 1 – Duplicação de links no mesmo bloco de conteúdo

    URLs a verificar:

    Recomendações:

    • Remover a duplicação de links com o mesmo destino dentro do mesmo bloco de conteúdo
    • Garantir a existência de apenas um elemento interativo principal por card/conteúdo
    • Evitar múltiplos elementos <a> adjacentes a apontar para o mesmo URL no mesmo contexto informacional
    • Quando o padrão utilizado for baseado em cards, recomenda-se a utilização de uma abordagem semelhante ao padrão stretched-link (ex.: Bootstrap), onde existe apenas um link principal e a área clicável é estendida visualmente para toda a área do card
    • Garantir que imagem, título e restantes elementos do card pertencem ao mesmo alvo interativo, sem duplicação de foco ou de navegação
    • Caso a imagem seja meramente decorativa, garantir que não está estruturada como uma imagem-link nem constitui um elemento interativo autónomo. Imagens decorativas não devem ser clicáveis nem receber foco

  • issue #6 Listagem de conteúdos sem estrutura semântica adequada

    etiqueta: chk 10 webetiqueta: R 8.3etiqueta: NOK

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

    Evidências:
    Na página principal, têm várias secções em que cada item é apresentado como um conjunto de conteúdos relacionados (imagem, data, título, descrição e ligação para detalhe), estruturado com múltiplos elementos <div>.

    No entanto, estes itens não estão inseridos numa estrutura semântica de lista (<ul> / <li>), apesar de representarem claramente uma listagem de conteúdos homogéneos.

    Image

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

    Como consequência, as tecnologias de apoio não conseguem identificar programaticamente que estes elementos pertencem a um conjunto, nem o número total de itens existentes.

    Quando os estilos CSS são desativados, os conteúdos passam a ser apresentados como blocos isolados, sem indicação clara da relação entre si, dificultando a compreensão da estrutura da informação.

    URLs a verificar:

    Recomendações:

    • Deve ser verificado este padrão em todo o website.
    • Os conjuntos de conteúdos que representem listagens (ex.: documentos, notícias, resultados) devem ser estruturados semanticamente como listas (<ul> ou <ol>), com cada item representado por um <li>.
    • Cada item da lista deve agrupar toda a informação relacionada (categoria, título, descrição e ações) dentro do respetivo <li>.
    • Evitar a utilização exclusiva de elementos genéricos (<div>) para representar agrupamentos de conteúdos.
    • Validar com leitores de ecrã para garantir que o agrupamento e o número de itens são corretamente anunciados.

Requisito 8.5 - A maquetização da página é feita sem recorrer ao elemento table

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #4 A maquetização da página recorre indevidamente ao elemento `<table>` para estruturação visual

    etiqueta: chk 10 webetiqueta: NOKetiqueta: R 8.5

    A maquetização da página é feita sem recorrer ao elemento <table>.
    – ver requisito 8.5 na lista 10 aspetos

    Evidências:
    Observa-se a utilização do elemento <table> com a finalidade de construção de layout e organização visual da página, em vez de ser utilizado exclusivamente para apresentação de dados tabulares estruturados.

    Neste caso, a estrutura apresentada recorre a uma <table> para organizar blocos de conteúdo correspondentes a datas e alinhamento de programação, onde a informação não representa uma verdadeira relação tabular com cabeçalhos semânticos associados.

    A tabela é utilizada como ferramenta de maquetização, incluindo células (<td>) para representar títulos de secção (datas) e conteúdos de diferentes colunas, sem definição de estrutura semântica adequada para dados tabulares.

    Image

    Figura 1 - Utilização de elemento <table> para estruturação visual de conteúdos em vez de dados tabulares

    URLs a verificar:

    Recomendações:

    • Evitar a utilização do elemento <table> para fins de layout ou maquetização visual da página
    • Utilizar estruturas semânticas adequadas como <div>,
      e
      ` para organização de conteúdo
    • Os títulos "Programação" e as respectivas datas devem ser estruturados como cabeçalhos
    • Reservar o elemento <table> exclusivamente para apresentação de dados tabulares com relação semântica entre linhas e colunas
    • Validar a estrutura semântica da página com tecnologias de apoio para garantir correta interpretação da informação

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 #32 Modal inacessível para tecnologias de apoio

    etiqueta: chk 10 webetiqueta: R 9.1etiqueta: NOK

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

    Evidências:

    Quando a caixa de diálogo é ativada, o foco do navegador permanece no conteúdo de fundo da página (links ou campos de texto do site) em vez de ser transferido automaticamente para o primeiro elemento interativo da modal (ex: botão "Fechar").

    Image

    URL:

    https://www.oeiras.pt/

    Recomendações:

    • Quando a caixa de dialogo é aberta o foco deve ser posicionado no 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 #36 Foco não fica limitado a caixa de diálogo

    etiqueta: chk 10 webetiqueta: R 9.2etiqueta: NOK

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

    Evidências:

    A navegação por teclado e leitores de ecrã não fica limitada aos elementos da caixa de diálogo. Durante a navegação, é possível interagir com elementos subjacentes à caixa de diálogo, fora do seu contexto.

    Image

    URL:

    Recomendações:

    • Recomenda-se prender o foco do teclado dentro da dialog utilizando um script/evento no JavaScript ou na linguagem apropriada.
    • Quando o utilizador navega com TAB a partir do último elemento focável, o foco deve voltar para o primeiro elemento focável.
    • Quando o utilizador navega com SHIFT+TAB a partir do primeiro elemento focável, o foco deve mover‑se para o último elemento focável.

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #37 A caixa dialogo não pode ser encerrada através da tecla ESC ou fechar

    etiqueta: chk 10 webetiqueta: NOKetiqueta: R 9.3

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

    Evidências:

    Verifica‑se que a caixa de diálogo não pode ser encerrada através da tecla ESC e também não possui um botão dedicado para fechar. Atualmente, para sair da modal é necessário acionar um dos botões “Aceitar todos”, “Rejeitar todos” ou “Guardar”, o que não é explícito tal como um botão de "Fechar".

    Image

    URL:

    https://www.oeiras.pt/web/guest

    Recomendações:

    • Idealmente podem implementar um mecanismo que permita o encerramento das janelas modais através da tecla ESC.
    • Devem incluir um botão de fechar claramente identificado na caixa de diálogo, permitindo ao utilizador encerrar o componente de forma simples e independente.
    • Os controlos não estão acessíveis através do teclado nem de leitores de ecrã, pelo que devem ser corretamente estruturados utilizando o atributo href. Esta situação deve ser revista em conjunto com a issue: https://github.com/a11y-PT/report_055/issues/48

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:

  • issue #38 Ao fechar a caixa de diálogo o cursor não retorna ao elemento que o acionou

    etiqueta: chk 10 webetiqueta: NOKetiqueta: R 9.4

    Quando a caixa de diálogo fecha, o foco (cursor do Browser) deve voltar ao elemento interativo que a invocou
    – ver requisito 9.4 na lista 10 aspetos

    Evidências:

    Ao fechar a modal de configurações de cookies, o foco não é devolvido ao elemento que a acionou (botão Configurações). Em vez disso, o foco é reposicionado em outro elemento da página.

    Image

    URL:
    https://www.oeiras.pt/web/guest

    Recomendações:
    Recomenda-se que ao fechar a modal, o foco seja devolvido ao elemento que a acionou.

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 #67 Nos ficheiros PDF não é possível, extrair o conteúdo textual para formato TXT

    etiqueta: chk 10 webetiqueta: R 10.1etiqueta: NOK

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

    Evidências:

    Foi verificado que, em alguns documentos PDF, não é possível extrair o conteúdo textual para formato TXT.

    Esta situação indica que os documentos poderão ter sido disponibilizados como imagem digitalizada, sem reconhecimento ótico de caracteres (OCR), impedindo o acesso ao conteúdo textual por tecnologias de apoio e outras ferramentas de processamento de texto.

    Image

    Figura 1 - Exemplo de um PDF onde não foi possível extrair o texto .

    URLs a verificar:

    Recomendações:

    • Garantir que os documentos PDF disponibilizados permitem a extração do conteúdo textual para formato TXT.
    • Aplicar Reconhecimento Óptico de Caracteres (OCR) da Adobe. aos documentos que se encontrem em formato de imagem digitalizada.
    • Validar, após a conversão, que o texto pode ser selecionado, copiado e extraído por tecnologias de apoio e ferramentas de leitura.

Checklist Conteúdo

etiqueta: NOK

Nível de conformidade:

  • Checklist Conteúdo: 0.0% (0/17)
    • Requisitos avaliados: 17 (17 aplicáveis)
    • Requisitos NOK: 17

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 #21 Falta de resumo visível na página principal

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

    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 principal do website do Portal Institucional do Município de Oeiras, não aparece presente um resumo breve do próposito do site.

    Image

    Imagem da página principal sem fazer scroll

    URL's a verificar:

    Recomendações:

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

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

    Image

    Imagem exemplo de uma frase de propósito do website selo.usabilidade.gov

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

etiqueta: NOK

Lista de evidências recolhidas:

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

etiqueta: NOK

Lista de evidências recolhidas:

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 #24 Informação da Entidade Responsável Não Apresentada por Extenso

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

    Todas as páginas devem apresentar o nome da entidade responsável pelos conteúdos publicados no site. O nome da entidade pode ser apresentado através de um logótipo ou texto, mas deve estar por extenso.

    Apesar de existir no rodapé o logotipo da entidade e informação dos contactos. Observamos que o nome da entidade responsável não está disponível por extenso.

    Image

    Imagem do rodapé sem o nome da entidade responsável escrito em extenso.

    URL's a verificar:

    Recomendações:

    Deve ser adicionado o nome da entidade por extenso em todo o website, como é possível observar no acessibilidade.gov.pt:

    Image

    Imagem de exemplo do rodapé do acessibilidade.gov.pt

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 #17 O conteúdo do site fica desformatado em resoluções mais pequenas

    etiqueta: chk conteúdoetiqueta: R 2.1etiqueta: NOK

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

    Evidências:

    • Todos os conteúdos do site devem ser responsivos para garantir a sua legibilidade na maioria das resoluções e quando são escalados para tamanhos superiores.

    O website apresenta inconsistências na variação dos tamanhos de letra em resoluções mais reduzidas. Com a navegação verificou‑se que, ao alterar a resolução para um formato mobile, o texto de botões do menu principal ficam desformatado e com uma dimensão inferior à recomendada, comprometendo a legibilidade. (Figura 1 e 2)

    Image

    Figura 1 - Textos dos elementos interativos de navegação apresentam tamanho de letra variável com apenas 10px em dispositivos móveis

    Image

    Figura 2 - Texto variável e tamanho de letra de apenas 14px em iPad Mini

    URLs a verificar

    Recomendações:
    É necessário a revisão em todo website. Para correção das páginas adaptadas de modo a assegurar que o conteúdo se reorganiza corretamente e permanece totalmente utilizável em diferentes resoluções, tamanhos e orientações de ecrã, sem perda de informação ou funcionalidade.

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

    etiqueta: chk conteúdoetiqueta: R 2.1etiqueta: NOK

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

    Evidências:

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

    O website possui informações primárias com tamanho inferior a 12pontos(16px), como os textos dos Cookies com tamanho de letra inferior ao recomendado, por exemplo no corpo de texto e botões com apenas 15px(Figura 1 e 2)

    Image

    Figura 1 - Verificação do tamanho do texto nos Cookies

    Image

    Figura 2- Verificação do tamanho de texto nos botões com apenas 15px

    Há informações úteis no corpo de texto com tamanho inferior ao recomendado. Por exemplo informações de contactos, localizações e horários de atentimento da página Contactos com apenas 14px. (Figura 3)

    Image

    Figura 3- Verificação do tamanho de texto em informações úteis

    URLs a verificar

    Recomendações
    É necessário ser corrigido 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 #11 A informação secundária têm um tamanho de letra inferior a 10pt (equivalente a 13px)

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

    Evidências:

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

    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 Pesquisa ao pesquisar por “biologia”, que os textos apresentados sobre a numeração/quantidades de notícias associadas as suas categorias possuem valor de apenas 12.8px. (Figura 1 e 2)

    Image

    Figura 1 - Verificação do tamanho de letra em números com valor inferior ao recomendado

    Image

    Figura 2 - Quantidade de pesquisas com números que possuem tamanho de letra inferior ao recomendado

    Esta dimensão reduzida compromete a legibilidade e cria barreiras para utilizadores com baixa visão ou que necessitem de ampliar o conteúdo.


    URLs a verificar

    Recomendações
    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.3 - Blocos e linhas de texto com largura não superior a 100 caracteres

etiqueta: NOK

Lista de evidências recolhidas:

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:

  • issue #14 O espaçamento entre linhas está abaixo do recomendado

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

    Evidências:

    • Para assegurar uma boa leitura, o espaçamento entre linhas não deve ser inferior a 1.5x em relação ao tamanho do texto a ser analisado.

    Na página Recrutamento, há blocos de textos com espaçamento inferior ao recomendado. Por exemplo, no banner, a secção “Notícias” com espaçamento de 25px para um tamanho de letra de 20px. (Figura 1)



    Image

    Figura 1 - Textos com espaçamento inferior ao recomendado.

    Além disso o texto do Banner Qualidade do ar com espaçamento de 24px para um tamanho de letra de 18px. (Figura 2)



    Image

    Figura 2 - Textos destaques com espaçamento inferior ao recomendado

    URLs a verificar

    Recomendações:
    Para a evidência da figura 01 apresentada, o espaçamento deveria ser, no mínimo 30px. Já para figura 02 o espaçamento deveria ser, no mínimo 27px. É necessário rever todo website para garantir o espaçamento mínimo recomendado, relativo ao tamanho da letra.

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #27 Excesso de opções no subnível do menu de navegação

    etiqueta: chk conteúdoetiqueta: NOKetiqueta: R 3.1

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

    Evidências:

    O menu principal do website do Portal Institucional do Município de Oeiras contém secções como “Viver”, “Serviços” e “Município”, ultrapassando o limite recomendado de 9 opções. Um número excessivo de itens no menu pode dificultar a navegação e a tomada de decisão por parte do utilizador.

    Image

    Imagem do menu principal com várias categorias a superar as 9 opções.

    Nota:

    O subnível “Serviços” do menu contém várias opções que ultrapassam os limites da modal, tornando os links difíceis de visualizar e aceder. Esta situação compromete a legibilidade e a navegação, especialmente em dispositivos com áreas de visualização reduzidas.

    URL's a verificar:

    Recomendações:

    Deve ser revista a estrutura do menu principal, reduzindo o número de opções apresentadas ao utilizador. Sempre que possível, os conteúdos devem ser reorganizados e agrupados de forma lógica em categorias mais abrangentes, promovendo uma navegação mais simples, clara e intuitiva.

    Com vista à melhoria da usabilidade e conformidade com os princípios de acessibilidade, recomenda-se:

    • Reduzir o número de opções no subnível, agrupando conteúdos relacionados sob categorias mais abrangentes.

    • Reorganizar a arquitetura de informação para garantir uma hierarquia mais simples e intuitiva.

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #31 Posicionamento inconsistente do menu principal entre páginas

    etiqueta: chk conteúdoetiqueta: NOKetiqueta: R 3.2

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

    Evidências:

    Na página inicial do Portal Institucional do Município de Oeiras, sem interação de scroll, o menu principal encontra-se posicionado na parte inferior do ecrã. No restante website, o mesmo menu é apresentado na parte superior.

    Esta diferença de posicionamento cria inconsistência na navegação e pode dificultar a compreensão da estrutura do website, especialmente para utilizadores com dificuldades visuais, cognitivas ou que dependem de padrões consistentes de navegação.

    Image

    Imagem do menu principal na página inicial posicionado na parte inferior do ecrã

    Image

    Imagem do menu principal na página inicial posicionado na parte superior do ecrã

    Nota:

    Os breadcrumbs também encontra-se certas vezes posicionados em posições diferentes pelo website.

    Image

    Imagem do breadcrumb em baixo do slider.

    Image

    Imagem do breadcrumb por cima do slider.

    URL's a verificar:

    Recomendações:

    • Garantir consistência no posicionamento do menu principal entre todas as páginas do website.
    • Manter o menu principal numa localização previsível e uniforme ao longo da navegação.
    • Validar a solução através de testes de usabilidade e acessibilidade com utilizadores.

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 #26 Falta de identificação complementar nas hiperligações

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

    Foi identificado um problema de acessibilidade relacionado com a identificação visual de links no website. Atualmente, existem situações em que os links não estão devidamente diferenciados do texto normal, sendo identificáveis apenas através da cor ou de interação (hover), o que não cumpre as boas práticas de acessibilidade. Segue em seguida alguns exemplos encontrados:

    Image

    Imagem de hiperligações de texto na página inicial com identificação complementar apenas em hover.

    Image

    Imagem dos breadcrumbs sem qualquer indicação visual de hiperligação. Disponível em: https://www.oeiras.pt/palacio-do-marques

    URL's a verificar:

    Recomendações:

    Recomenda-se a revisão transversal do website, de forma a garantir que todas as hiperligações possuam elementos de identificação adicionais à cor e não dependam exclusivamente do estado de hover para serem reconhecidas como links. Para assegurar a correção desta situação, recomenda-se que as hiperligações:

    • Sejam visualmente distinguíveis do texto normal sem depender exclusivamente da cor;
    • Incluam sublinhado ou outro indicador visual consistente;
    • Mantenham consistência em todos os estados (normal, hover, focus).

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 #9 Inconsistências de adaptação responsiva e apresentação de conteúdos em dispositivos móveis

    etiqueta: chk conteúdoetiqueta: R 4.2etiqueta: NOK

    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

    Verificámos que alguns conteúdos da página inicial do website Município de Oeiras não se adaptam corretamente a determinados tamanhos de ecrã em dispositivos móveis.

    Verificamos que os ícones das redes sociais se sobrepõem à secção “Contactos Úteis”, comprometendo a correta apresentação e leitura dos conteúdos da página. (Figura 01)

    Image

    Figura 01 — Sobreposição dos ícones das redes sociais à secção “Contactos Úteis” em resolução móvel.

    Verificámos que, na página Vinho Villa Oeiras, a galeria de imagens não apresenta controlos visíveis que permitam navegar pelos restantes conteúdos disponíveis.

    Foi identificado que existem imagens adicionais fora da área inicialmente visível, sem qualquer indicação visual, como setas de navegação ou indicadores de posição, dificultando a perceção de que a galeria contém mais conteúdos, especialmente em dispositivos móveis. (Figura 02)

    Image

    Figura 02 — Galeria de imagens com conteúdos adicionais não visíveis e sem mecanismos de navegação aparentes.

    Verificámos que, na página Denúncia ao abrigo do Regime Geral de Proteção de Denunciantes de Infrações, o Índice de acesso rápido às diferentes secções da página deixa de estar disponível em resoluções móveis, reduzindo os mecanismos de navegação disponibilizados ao utilizador. (Figura 03)

    Image

    Figura 03 — Índice de navegação indisponível em dispositivos móveis.

    URL a verificar:

    Recomendações:
    Recomenda-se a revisão do comportamento responsivo dos componentes da interface, garantindo que os conteúdos se adaptam corretamente às diferentes dimensões de ecrã sem cortes, sobreposições ou necessidade de deslocação horizontal.

    Deverá ainda ser assegurado que galerias, carrosséis e outros componentes com conteúdos adicionais disponibilizam mecanismos de navegação visíveis e percetíveis, permitindo ao utilizador identificar facilmente a existência de mais conteúdos disponíveis.

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #47 Elementos interativos dependentes de interação por hover para visualização

    etiqueta: chk conteúdoetiqueta: NOKetiqueta: R 5.1

    Não existem elementos interativos acionados apenas com a passagem do rato.
    – ver requisito 5.1 na lista Conteúdo

    Evidências:

    Verificámos que, na galeria da página "Vinho Villa Oeiras", o controlo de expansão das imagens apenas é apresentado quando o utilizador passa o cursor sobre a fotografia.

    Esta funcionalidade não se encontra permanentemente visível, dificultando a sua identificação em dispositivos sem interação por hover. (Figura 01)

    Image

    Figura 01 — Controlo de expansão da galeria apenas é apresentado no estado hover.

    URL a verificar:

    Recomendações:

    Os elementos interativos não devem depender exclusivamente da interação por hover para serem identificados ou utilizados. Os controlos associados às imagens devem permanecer visíveis ou disponibilizar uma alternativa equivalente em dispositivos sem interação por rato.

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 #42 Elementos interativos com área clicável inferior à dimensão mínima recomendada

    etiqueta: chk conteúdoetiqueta: NOKetiqueta: R 5.2

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

    Evidências:

    Verificámos vários elementos interativos na página inicial do website Município de Oeiras com dimensões inferiores à área mínima recomendada de 44x44px.

    O botão associado ao ícone de pesquisa possui 23x21px, não cumprindo a dimensão mínima de 44x44px definida pelo presente critério. (Figura 01)

    Image

    Figura 01 — Botão de pesquisa apresenta área clicável inferior à dimensão mínima recomendada.

    As setas de navegação do carrossel de publicações apresentam 40px, não cumprindo a dimensão mínima de 44px definida pelo presente critério. (Figura 02)

    Image

    Figura 02 — Setas de navegação do carrossel apresentam área clicável inferior à dimensão mínima recomendada.

    Os elementos de paginação do banner principal com 31x12px, não cumprindo a dimensão mínima de 44x44px definida pelo presente critério. (Figura 03)

    Image

    Figura 03 — Elementos de paginação do banner principal apresentam dimensão inferior à mínima recomendada.

    O botão lateral “Meu Bairro” apresenta uma área clicável inferior à dimensão mínima recomendada. Foi identificada uma largura aproximada de 39px, não cumprindo a dimensão mínima de 44x44px definida pelo presente critério. (Figura 04)

    Image

    Figura 04 — Botão lateral “Meu Bairro” apresenta área clicável inferior à dimensão mínima recomendada.

    Verificámos que, na página de notícia Oeiras distinguida como a primeira autarquia Pet Friendly do País, os ícones de partilha para redes sociais, nomeadamente Facebook e X (Twitter), possuem dimensões de 40.64 × 38.4 px, inferiores à área mínima recomendada para elementos interativos.
    (FIgura 05)

    Image

    Figura 05 — Ícones de partilha em redes sociais com área clicável inferior ao mínimo recomendado.

    Verificámos que, na galeria da página Vinho Villa Oeiras, o elemento de controlo de expansão das imagens possui 32px de dimensão, valor inferior ao recomendado.
    Adicionalmente, o botão de fechar ("X") associado à visualização ampliada das imagens apresenta uma área clicável de 32px.
    (Figura 06)

    Image

    Figura 06 — Botão de fechar com área clicável inferior ao mínimo recomendado.

    URL a verificar:

    Recomendações:

    Os elementos interativos identificados devem garantir uma área clicável mínima de 44x44px, conforme definido pelo presente critério. Esta dimensão deve ser assegurada tanto nos controlos de navegação, botões e elementos de paginação, como nos restantes componentes interativos do website, facilitando a sua utilização em dispositivos táteis.

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 #44 Hierarquia visual insuficiente entre ações principais e elementos informativos

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

    Evidências:

    Verificámos que, no website do Município de Oeiras , vários elementos da interface utilizam o mesmo destaque visual.

    Foi identificado que o botão de submissão do campo de subscrição de publicações, correspondente à ação principal deste componente, utiliza a mesma cor de destaque aplicada em cartões de conteúdo, separadores, elementos de navegação e ícones de redes sociais, dificultando a sua identificação face aos restantes elementos da página. (Figura 03)

    Image

    Figura 01 — Botão de submissão da subscrição utiliza o mesmo destaque visual presente noutros componentes da interface.

    Verificámos que na página Pesquisa, no menu lateral a ação "Limpar" associada aos filtros apenas é apresentada após a seleção de uma ou mais opções.

    Esta abordagem dificulta a descoberta da funcionalidade pelos utilizadores, uma vez que a ação não se encontra permanentemente disponível na interface. (Figura 02)

    Image

    Figura 02— Ação “Limpar” apenas é apresentada após a seleção de filtros.

    URL a verificar:

    Recomendações:

    As ações principais devem apresentar um destaque visual claramente distinto dos restantes elementos da interface, permitindo a sua rápida identificação.

    As ações associadas aos componentes, como a opção "Limpar" nos filtros, devem também permanecer visíveis e facilmente identificáveis pelos utilizadores.

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #46 Elementos interativos sem diferenciação visual clara ou comportamento consistente de interação

    etiqueta: chk conteúdoetiqueta: NOKetiqueta: R 5.4

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

    Evidências:

    Verificámos vários elementos interativos na página inicial do website Município de Oeiras que apresentam reduzidos indicadores visuais de interação, dificultando a perceção dos componentes como elementos clicáveis.

    Os elementos do menu principal, como “viver”, “descobrir”, “investir”, “serviços” e “município”, apresentam-se visualmente como texto simples, sem indicadores claros de interação.
    Adicionalmente, não existem alterações visuais relevantes no hover que permitam identificar facilmente os elementos como clicáveis. (Figura 01)

    Image

    Figura 01 — Itens do menu principal não aparentam ser elementos interativos.

    Em vários banners da página inicial, botões como “Consulte a programação”, “Saiba mais” e “Mais informações” apresentam-se visualmente integrados nas imagens de fundo, dificultando a identificação clara da área clicável.

    Adicionalmente o botão “Ver mais” do bloco “Serviço de Proteção Civil de Oeiras” apresenta reduzidos indicadores visuais de interação. (Figura 02)

    Image

    Figura 02 — Botões dos banners principais apresentam-se visualmente integrados nas imagens de fundo, dificultando a identificação da área clicável.

    Os ícones de redes sociais presentes no rodapé do website Município de Oeiras apresentam reduzidos indicadores visuais de interação. Os elementos mantêm o mesmo aspeto no hover, dificultando a perceção dos ícones como elementos clicáveis.
    (Figura 03)

    Image

    Figura 03 — Ícones de redes sociais apresentam reduzidos indicadores visuais de interação.

    Verificámos que, na página Recolha e Valorização de Resíduos Urbanos, a imagem disponibilizada não apresenta qualquer elemento interativo que indique a possibilidade de ampliação, nem contém uma indicação clara de que, ao clicar, o utilizador será redirecionado para uma nova aba com a imagem ampliada. (Figura 04)

    Image

    Figura 04 — Imagem clicável sem indicação visual clara da funcionalidade de ampliação.

    URL a verificar:

    Recomendações:

    Os elementos interativos devem apresentar indicadores visuais claros de interação, permitindo identificar facilmente as áreas clicáveis e os diferentes estados dos componentes.

  • issue #45 Elementos interativos com contraste insuficiente relativamente ao fundo

    etiqueta: chk conteúdoetiqueta: NOKetiqueta: R 5.4

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

    Evidências:

    Verificámos que, na página inicial do website Município de Oeiras, os elementos de paginação do banner principal apresentam um contraste de 1.07:1 face ao fundo do componente, dificultando a sua identificação visual e tornando-os praticamente impercetíveis em alguns slides do banner. (Figura 01)

    Image

    Figura 01 — Elementos de paginação do banner principal apresentam contraste inferior ao mínimo recomendado.

    Verificámos que, na página 50 Anos do 25 de Abril, os elementos de paginação do carrossel utilizados para percorrer os conteúdos apresentam um contraste de 1.02:1. Valor inferior ao mínimo recomendado pelas WCAG para componentes visuais da interface. (Figura 02)

    Image

    Figura 02 — Elementos de paginação do carrossel da secção “50 Anos do 25 de Abril” apresentam contraste inferior ao mínimo recomendado.

    Verificámos que, na galeria da página Vinho Villa Oeiras, o elemento utilizado para ampliar as imagens apresenta contraste insuficiente face ao fundo onde se encontra inserido.

    Foi identificado que o ícone de expansão das imagens apresenta um contraste de 1.61:1, valor inferior ao mínimo recomendado. (Figura 03)

    Image

    Figura 03— Elemento de expansão da galeria apresenta contraste inferior ao mínimo recomendado.

    URL a verificar:

    Recomendações:

    Os elementos gráficos interativos devem apresentar contraste suficiente face ao fundo e manter indicadores visuais claros nos diferentes estados de interação (hover, foco e seleção). Desta forma, os utilizadores conseguem identificar facilmente os componentes clicáveis e compreender o seu estado de utilização.

Outras violações

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

Lista de evidências recolhidas:

  • issue #66 Outras violações - Website em baixa repetidamente

    etiqueta: melhoriaetiqueta: outras violações

    Evidências:
    Durante a utilização e análise do website, ocorre frequentemente a apresentação de mensagens de erro “Access Denied” em diferentes páginas. Apesar de conseguirmos atualizar e retornar a navegação, o problema é inconsistente e persistente em diferentes dispositivos e plataformas. Para além da recorrência o erro indica possíveis problemas de estabilidade ou comunicação com o servidor, a mensagem de erro é apresentada exclusivamente em inglês. (Figura 1, 2 e 3)

    Image

    Figura 1 - Imagem do erro apresentado no dispositivo iPhone 14 Pro Max (iOS)

    Image

    Figura 2 - Imagem do erro apresentado no dispositivo Samsung Galaxy S8+(Android)

    Image

    Figura 3 - Imagem do erro apresentado no desktop

    A ocorrência de erros expostos de forma pouco clara durante a navegação representa uma experiência particularmente frustrante, comprometendo a confiança do utilizador e a fluidez de interação com o website.

    Além disso, considerando que o website é publicado em Português, a grande parte dos seus utilizadores terá o português como língua principal, esta situação pode dificultar a compreensão do problema e gerar confusão ou insegurança relativamente ao estado da plataforma. A apresentação de mensagens de erro técnicas não traduzidas, compromete a clareza da comunicação com o utilizador e prejudica a experiência de utilização, sobretudo para utilizadores com menor literacia digital ou menor conhecimento de línguas estrangeiras.

    URLs a verificar

    Recomendações:
    Recomenda-se a análise e correção das causas técnicas que originam os erros “Access Denied”, de forma a reduzir a frequência destas ocorrências e melhorar a estabilidade geral da plataforma. Adicionalmente, as mensagens de erro apresentadas ao utilizador devem:

    • ser disponibilizadas em português;
    • respeitar o idioma atualmente selecionado no website, caso exista suporte multilíngue.

  • issue #65 Outras violações - Há conteúdos em inglês na versão portuguesa do website

    etiqueta: melhoriaetiqueta: outras violações

    Evidências:

    • Verificámos uma inconsistência linguística, uma vez que o site está em português mas há botões e conteúdos com o textos alternativos em inglês.

    
O website possui elementos interativos como botões da Agenda, que possuem textos alternativos em inglês, com aria-label="Arrow Right" e  aria-label="left arrow", dificultando a compreensão para utilizadores do idioma português, língua em que o site é implementado. (Figura 1 e 2)


    Image

    Figura 1 - Setas interativas em inglês impacta na experiência com leitor de ecrã NVDA

    Image

    Figura 2 - Verificação do texto alternativo das setas interativas da “Agenda”

    A página Fundos Europeus apresenta problemas de inconsistência linguística. Apesar de a página estar definida e apresentada no idioma português (PT), verifica‑se a existência de conteúdos textuais em inglês. Esta inconsistência linguística é visível, por exemplo, nas descrições de todos os “Projetos executados e/ou em execução” por exemplo a descrição do projeto "NEW EPOCH" na (Figura 3)


    Image

    Figura 3 - Descrições dos projetos no idioma inadequado

    A mistura de idiomas pode causar confusão aos utilizadores, afetar a compreensão da informação e constituir uma barreira à acessibilidade, especialmente para pessoas com dificuldades cognitivas, utilizadores de leitores de ecrã ou cidadãos com menor proficiência em inglês. 

    URLs a verificar

    Recomendações:
    Recomenda‑se a uniformização do idioma de todos os conteúdos apresentados na página, garantindo que o texto se encontra integralmente em português quando o idioma principal definido é PT. Deverá ser assegurado que quaisquer termos, componentes ou conteúdos sejam devidamente traduzidos e revistos, promovendo a coerência linguística, a clareza da informação.

  • issue #63 Outras violações -Foco não está visível na navegação por teclado e leitor de ecrã

    etiqueta: melhoriaetiqueta: outras violações

    Evidências
    Ao navegar pelo website utilizando o teclado ou leitor de ecrã, nem sempre o indicador de foco se encontra visível, dificultando significativamente a navegação, em particular para utilizadores que dependem exclusivamente deste meio de interação.

    Durante a navegação sequencial através da tecla TAB, em alguns momentos o foco não é apresentado de forma perceptível, sendo apenas possível inferir a sua existência através da barra de estado do navegador, o que não constitui uma solução acessível nem adequada. Por exemplo, no rodapé da página Ambiente (Figura 1)

    Image

    Figura 1 – Exemplo de ausência de foco visível na navegação por teclado

    O problema se repete em páginas interiores e em todo website, por exemplo nas componentes da página Agenda que não são circunscritas pelo foco, e ainda existem opções do caledário que são escondidas visualmente, anunciadas apenas através do leitor de ecrã, por exemplo a opção “Ano”. (Figura 2)

    Image

    Figura 2 – Exemplo de foco visível mas não circunscreve corretamente as componentes do calendário para indicar interatividade clicável

    Sendo assim não é possível identificar visualmente a posição do utilizador em cada momento da navegação. Esta situação pode levar o utilizador a perder a noção da sua posição na página, comprometendo a usabilidade e a acessibilidade do website.

    URLs a verificar

    Recomendações:
    Garantir que todos os elementos interativos do website apresentam um indicador de foco visível, suficientemente contrastante e consistente, sempre que recebem foco através da navegação por teclado.

    • O estilo de foco deverá:
    • Ser claramente percetível visualmente (ex.: contorno, sublinhado ou mudança de cor);
    • Manter contraste adequado em relação ao fundo;
    • Não ser removido através de regras CSS como outline: none sem alternativa equivalente;
    • Acompanhar corretamente a ordem lógica da navegação por teclado.

    Esta melhoria é essencial para assegurar uma navegação acessível a utilizadores com deficiência visual, motora ou cognitiva

  • issue #62 Outras violações - Existem páginas que apresentam quebra de layout

    etiqueta: melhoriaetiqueta: outras violações

    Evidências:
    Verificámos uma quebra de layout nos elementos interativos da paginação. Por exemplo, na página da Pesquisa, com problemas de sobreposição na componente de paginação, nomeadamente ao nível da indicação da página atual, onde a componente surge visual e estruturalmente desformatada sobreposta ao menu principal.(Figura 1)

    Image

    Figura 1 - Problemas de quebra de layout na componente de Paginação

    Image

    Figura 2 - Opções dos filtros incompletas, visíveis apenas com abertura da caixa de seleção

    Esta situação compromete a legibilidade, a distinção entre elementos e a correta perceção da hierarquia da interface, podendo causar dificuldades na identificação do estado atual da paginação.

    URLs a verificar

    Recomendações:
    Deve ser ajustado o posicionamento e a hierarquia visual dos elementos, definição de limites consistentes de largura e extensão para a componente de paginação, garantindo a sua apresentação uniforme em todas as páginas. Recomenda-se assegurar uma separação clara entre componentes, validando o comportamento em diferentes resoluções para um comportamento responsivo adequado e níveis de zoom.

  • issue #61 Outras violações - Duplicação de informação e inconsistências visuais na componente de acordeão

    etiqueta: melhoriaetiqueta: outras violações

    Evidências
    O componente de acordeão apresenta, de forma geral, um comportamento funcional , sendo corretamente interpretado pelo leitor de ecrã (NVDA), que anuncia o estado dos itens como “expandido” ou “recolhido”.

    No entanto, foram identificados problemas relevantes ao nível da navegação e compreensão da informação. Durante a navegação com leitor de ecrã, verifica-se duplicação de conteúdos (títulos/links), o que gera ruído e dificulta a perceção clara dos elementos disponíveis e das suas ações (Figura 01)

    Image

    Figura 1 - Navegação com leitor de ecrã e duplicações de informação

    Além disso, o comportamento interativo e organização visual do acordeão contribui para uma experiência pouco clara, pois existem inconsistências visuais que afetam a interpretação da interface. Em particular, ao expandir um item (ex.: “Ano 2022”), é apresentada uma área lateral com aspeto de “caixa” vazia, que visualmente aparenta estar associada a outro item (ex.: “Ano 2024”). (Figura 02)

    Image

    Figura 2 - Estrutura visual do acordeão confusa para perceção do conteúdo

    Esta apresentação pode induzir em erro, levando os utilizadores a interpretar incorretamente a relação entre o conteúdo expandido e os restantes elementos.

    URLs a verificar

    Recomendações
    Recomenda-se a simplificação do padrão de interação, evitando o uso de acordeões quando não existe necessidade real de ocultar conteúdo. Nos casos em que a funcionalidade consiste apenas em navegação, os elementos devem ser disponibilizados diretamente como links, reduzindo complexidade e redundância garantindo que cada conteúdo é exposto apenas uma vez, de forma clara especialmente para utilizadores de tecnologias de apoio.

    • É necessário corrigir a apresentação visual do componente, assegurando que o conteúdo expandido está claramente associado ao respetivo item e que não existem áreas vazias ou elementos ambíguos que possam induzir interpretações erradas.

Significado das etiquetas utilizadas