Relatório Avaliação da Candidatura da Sítio Autárquico - Câmara Municipal de Alcobaça

Introdução

O website https://www.cm-alcobaca.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 aspetos54.5% (12/22)etiqueta: Não passa
Conteúdo81.3% (13/16)etiqueta: 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.

Verificámos também que a Declaração de Acessibilidade não se encontra corretamente afixada. Consulte o capítulo "Declaração de acessibilidade" para saber o que tem de corrigir.

Declaração de Acessibilidade

etiqueta: NOK

De acordo com o artigo 8º do DL n.º 83/2018, todos os sítios web e todas as aplicações móveis têm de ostentar uma Declaração de Acessibilidade. A Declaração é o documento na qual a organização evidencia o trabalho levado a efeito para tornar os seus conteúdos e serviços digitais mais acessíveis, disponibilizando ainda contactos para ajuda adicional.

Lista de evidências recolhidas:

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: 54.5% (12/22)
    • Requisitos avaliados: 27 (5 N/A excluídos, 22 aplicáveis)
    • Requisitos OK: 12
    • Requisitos NOK: 10
    • Requisitos N/A: 5

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

etiqueta: NOK

Lista de evidências recolhidas:

  • evidência: issue #9 Outras melhorias - O componente de paginação não está estruturado como <nav> e não tem aria-label

    etiqueta: R 1.1etiqueta: chk 10 webetiqueta: melhoria

    Problema

    O elemento de paginação em páginas como Marcas Identitárias ou Avisos é anunciado pelo leitor de ecrã apenas como “lista de 7 opções”, sendo também indicada a posição de cada link dentro da lista.

    Image

    Figura 1 - Paginação na página Marcas Identitárias.

    No entanto, não é fornecido pelo leitor de ecrã qualquer contexto adicional que identifique este componente como um elemento de navegação, o que dificulta a compreensão da sua finalidade.

    Recomendação

    Rever o elemento de página em todas as páginas:

    • Estruturar o elemento de paginação como <nav>.

    • Adicionar um aria-label para distinguir esse <nav> do <nav> principal. Por exemplo: <nav aria-label="Paginação"

  • evidência: issue #4 R 1.1 - Subopções do menu de mobile não estão estruturadas como listas

    etiqueta: R 1.1etiqueta: chk 10 webetiqueta: NOK

    Problema

    • Os elementos dos menus e submenus deverão estar todos estruturados como lista, recorrendo aos elementos <ul> e <li>.
      Nas subpopções de menu em mobile foram encontradas listas estruturadas como <div>. O leitor de ecrã não comunica que é uma lista, nem quantos elementos existem.
    Image

    Figura 1 - Inspect das subopções do menu em mobile revela que as opções estão apenas estruturadas como divs.

    • O botão que aparece como título desta subopção está a ser lido pelo leitor de ecrã como “Município, botão”. No entanto, a sua função é permitir a ação Voltar, saindo da secção Município, o que pode induzir o utilizador em erro.
    Image

    Figura 2 - Inspect do botão "Município" do menu de mobile revela que o texto está dentro do botão.

    Recomendação

    • Devem verificar que todas as opções de menu em desktop e mobile estão estruturados como lista, com elementso <ul><li>.
    • Além disso, o botão de voltar deve ter o aria-label ="Voltar" ou aria-label="Sair de Município" e o título Município deverá estar fora do botão, estruturado como <span>.
    • Devem também garantir que as subopções de nível 2 em mobile só são apenas lidas quando a subopção é aberta.

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

etiqueta: NOK

Lista de evidências recolhidas:

  • evidência: issue #8 R 1.2 - As subopções do menu em mobile não estão associadas ao botão de menu hambúrguer

    etiqueta: chk 10 webetiqueta: NOKetiqueta: R 1.2

    Problema

    Quando se navega com o teclado e com leitor de ecrã na versão mobile do site, o leitor de ecrã anuncia o botão do menu hambúrguer como estando fechado. No entanto, quando se avança para o elemento seguinte, são lidas as subopções do menu, mesmo sem este ter sido aberto.

    Image

    Figura 1 – Navegação por teclado na opção “Outros contactos” do menu hambúrguer, ainda fechado, na versão mobile do site.

    O mesmo acontece com as subopções de segundo nível:

    Image

    Figura 2 – Navegação por teclado na opção Saúde e emergência da opção "Contactos" do menu hambúrguer, ainda fechado.

    Recomendação

    Rever a estrutura do menu hambúrguer, para que em todas as páginas, o menu hambúrguer e as subopções apenas sejam lidas quando o utilizador realiza a ação de expandir o menu hambúrguer e as subopções.

    • Se o utilizador escolher expandir o menu, deve conseguir ler as subopções do menu.
    • Se o utilizador não expandir o menu, deve avançar para o elemento seguinte ao botão do menu hambúrguer, dependendo da página onde se encontra.

    Para mais informações de como estruturar, podem consultar a página Navigation Menu Button Example.

  • evidência: issue #2 R 1.2 - Subopções do menu principal em desktop não são acionáveis por hover/click e não têm pista visual

    etiqueta: chk 10 webetiqueta: NOKetiqueta: R 1.2

    Problema

    Existem subopções dentro dos submenus que não podem ser acedidas utilizando o rato Hover ou click na versão desktop. Apenas é possível aceder da navegação por teclado ou leitor de ecrã.

    Além disso, não existem indicadores visuais para sinalizar que existem subopções. Por exemplo, a subopção de nível 1 “Câmara Municipal” inclui a subopção de nível 2 “Executivo”, mas não apresenta qualquer elemento visual (como uma seta ou ícone) que indique a existência desse submenu.

    Image

    Figura 1 - Subopções do menu de primeiro nível

    Resolução

    • Tornar as setas a indicar a existência das subopções visíveis. No CSS devem rever o query border: 0 !important e width:auto aplicado a um query de min-width: 1200px.
    Image

    Figura 2 - CSS das setas do menu de navegação

    • As setas, quando visíveis, deve ter contrastar com o fundo bege, por isso não podem ser da cor branca. Atualmente, apenas existem setas brancas escondidas, que fazem contraste com o castanho do estilo do focus.
    Image

    Figura 3 - Subopções de menu de segundo nível

    • Deve ser possível abrir as subopções com o hover e/ou click do rato. Definir uma pseudo-class de :hover.

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

etiqueta: NOK

Lista de evidências recolhidas:

  • evidência: issue #3 R 1.3 - As imagens das setas das subopções do menu em mobile não têm texto alternativo

    etiqueta: R 1.3etiqueta: chk 10 webetiqueta: NOK

    Problema

    No menu de navegação em mobile existe, junto às opções e subopções do menu, um botão identificado visualmente por um ícone de seta. Este botão tem como função expandir e colapsar as subopções associadas à respetiva opção do menu.

    Importa referir que:

    • O texto da opção principal funciona como link para a página correspondente;
    • O botão com o ícone de seta é o elemento interativo responsável por revelar as subopções.

    O botão que contém o ícone de seta não possui texto alternativo nem nome acessível definido.

    Ao navegar com um leitor de ecrã, o elemento é anunciado apenas como “Botão”, sem qualquer indicação da sua finalidade ou estado (expandido/colapsado). Ao olharmos para o código dessas setas, verifica-se precisamente a ausência de nome acessível:

    <button class="info-parent__arrow">

    Isto impede que utilizadores de tecnologias de apoio compreendam a função do botão, a existência de subopções e o estado atual do submenu.

    Image

    Recomendação

    • Deve ser adicionado um nome acessível ao botão através do atributo aria-label, tal como já acontece em desktop (ex.: aria-label="Abrir submenu de Município", etc.).
    • Deve ainda ser utilizado o atributo aria-expanded para indicar o estado do submenu: aria-expanded="true" quando estiver expandido e aria-expanded="false" quando estiver colapsado.

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

etiqueta: NOK

Lista de evidências recolhidas:

  • evidência: issue #7 R 2.1 - Não existe um título <h1> marcado na página inicial em mobile

    etiqueta: chk 10 webetiqueta: NOKetiqueta: R 2.1

    Problema

    Na página inicial de mobile, não existe um <h1> atribuído, obrigando o utilizador a percorrer o url ou grande parte da página para perceber a sua estrutura e em que página se encontra.

    Image

    Figura 1 - Código HTML do logótipo na versão mobile do site.

    Image

    Figura 2 - Estrutura de títulos da página inicial na versão mobile do site, com um <h1> em falta.

    Recomendação

    Cada página deve ter um título principal (h1). No caso da página inicial deve estar atribuído ao logótipo, e irá assumir o alt da imagem, que deverá ser "Página inicial do Município de Alcobaça".

    • Na página inicial, o logótipo deve ser apenas uma imagem.

    • Nas páginas secundárias, o logótipo deve ser o link que remete para a página inicial.

    Devem replicar em mobile a mesma estrutura e lógica correta em desktop.

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:

  • evidência: issue #30 R 3.1 - 10 Aspetos

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

    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

  • evidência: issue #10 R 3.1 - Não existem tabelas no site, por isso não é aplicável a estrutura de cabeçalhos com <th>

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

    Problema

    No ficheiro Excel das evidências, consideram que a página Boletim contém tabelas, mas apresenta apenas uma lista, não uma estrutura de <table> nem conteúdo que necessite dessa estrutura.

    Resolução

    Colocar como "Não aplicável" no Excel dos 10 aspectos funcionais da candidatura, uma vez que parece não existem tabelas no site.

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

etiqueta: N/A

Lista de evidências recolhidas:

  • evidência: issue #31 R 3.2 - 10 Aspetos

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

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

  • evidência: issue #11 R 3.2 - Não existem tabelas no site, por isso não é aplicável a legenda estar marcado com o <caption>

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

    Problema

    No ficheiro Excel das evidências, consideram que a página Boletim contém tabelas, mas apresenta apenas uma lista, não uma estrutura de <table> nem conteúdo que necessite dessa estrutura.

    Resolução

    Colocar como "Não aplicável" no Excel dos 10 aspectos funcionais da candidatura, uma vez que parece não existem tabelas no site.

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:

  • evidência: issue #14 R 4.1 - Campos de input sem etiqueta (label) e estruturados como outros elementos

    etiqueta: chk 10 webetiqueta: NOKetiqueta: R 4.1

    Problema

    Existem campos de input que não estão estruturados como tal e sem label associada:

    Na página inicial

    • Campo da pesquisa não tem label associada ao campo, e o leitor de ecrã lê a informação do aria-label do input, não do <span> visualmente escondido.
    Image

    Figura 1 - HTML do campo da pesquisa

    • Campo do email para receber newsletter não tem label associada ao campo, e o leitor de ecrã lê a informação do aria-label do input, não do span visualmente escondido.
    Image

    Figura 2 - HTML do campo do email para receber newsletter

    • Checkbox dos termos e condições não tem a label associada ao input, porque a label encontra-se numa <div> e o input noutra <div>, quebrando a ligação adjacente do HTML nativo.
    Image

    Figura 3 - HTML da checkbox dos termos e condições

    • Campo de intervalo de datas não está estruturado como campo de input, nem tem uma etiqueta (<label>) associado. Não é possível interagir com esse campo através do teclado e leitor de ecrã.
    Image

    Figura 4 - HTML do campo de data picker da página inicial

    • Campo da categoria não está estruturado como uma combobox, mas como botão, não sendo possível navegar corretamente com o leitor de ecrã pela dropdown e compreender as opções que foram selecionadas.
    Image

    Figura 5 - HTML do campo da categoria da página inicial

    Na página Eventos, os mesmos problemas são encontrados no campo da categoria e intervalo de datas.

    Image

    Figura 6 - HTML do campo da categoria da página Eventos

    Image

    Figura 7 - HTML do campo de intervalo de datas da página Eventos

    Resolução

    • Devem garantir que todos os campos de edição, dropdowns, pesquisa, date pickers, são estruturados como <input> e com uma <label>. Oforda <label> deve ter o mesmo valor que o id do <input>, para que o leitor de ecrã consiga comunicar a informação da label do campo quando foca no componente, assim como o cursor surgir no respectivo campo de edição quando se clica na etiqueta.

    • No caso do campo de categoria devem estruturar como uma multi-select combobox.

    • No caso do campo de intervalo de datas devem estruturar como um date picker combobox, com uma label associada. Podem seguir o exemplo do elemento Date Picker Combobox Example da W3C. como referência.

    • No caso da checkbox, devem garantir que o input está associado à label. Podem consultar a página Labeling Controls - Checkbox da W3C como referência.

    • A label de todos os campos mencionados deve ficar visível e não ser escondida do leitor de ecrã através de <span> ou ser atribuída através de um aria-label. A label estar constantemente visível permite relembrar cognitivamente o que as pessoas estão a inserir nos campos.

    • Não é necessário a label estar fora do campo, quando o campo ainda não tem input inserido, mas quando o input é inserido, a

    • Não devem utilizar o placeholder do campo como substituto da label.

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

etiqueta: N/A

Lista de evidências recolhidas:

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

etiqueta: NOK

Lista de evidências recolhidas:

  • evidência: issue #15 R 5.3 - As imagens-link informativas não têm a informação extra do title correta

    etiqueta: chk 10 webetiqueta: NOKetiqueta: R 5.3

    Problema

    Foram colocados atributos title errados em imagens-link, como o botão da lupa.

    Quando se coloca o mouse hover nesse botão, aparece uma tooltip com esse title atribuído (title="Ícone de lupa"), o que não reflete a função do botão da mesma forma que o aria-label="Pesquisar". Uma pessoa com visão fica sem compreender a ação ao ler a tooltip do title.

    Image

    Figura 1 - HTML do botão de Pesquisa do topo da página

    Image

    Figura 2 - HTML do botão de Pesquisa da barra da pesquisa

    Resolução

    Devem rever as imagens para que seja atribuído um title a imagens-link e o valor do atributo corresponda à ação do elemento em que a imagem se encontra, não uma descrição da imagem. No caso da lupa, o title deve ser title="Pesquisar".

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

etiqueta: N/A

Lista de evidências recolhidas:

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

etiqueta: N/A

Lista de evidências recolhidas:

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

etiqueta: NOK

Lista de evidências recolhidas:

  • evidência: issue #17 R 8.4 - Quando se retira a CSS, a informação relevante não permanece visível

    etiqueta: chk 10 webetiqueta: NOKetiqueta: R 8.4

    Problema

    Quando se retira a CSS, não aparece visível nenhuma informação sobre o botão das redes sociais, incluindo o seu texto alternativo.

    Image

    Figura 1 - Botões das redes sociais do topo da página sem CSS

    Image

    Figura 2 - Botões das redes sociais abaixo do campo da pesquisa sem CSS

    Acontece que o HTML dessas imagens-link estão mal estruturadas, estando uma <div> dentro de um link (<a>).

    Image

    Figura 3 - HTML das imagens - links das redes sociais

    Resolução

    Remover a <div>, um elemento block, dentro do link (<a>), um elemento inline. Seguir a construção nativa HTML de um link que contém uma imagem.

    Além disso, garantir que os estilos CSS não estão aplicados a uma <div>, mas à imagem.

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:

  • evidência: issue #18 R 9.1 - Quando a modal é aberta, o foco não se move para um elemento dentro da modal

    etiqueta: chk 10 webetiqueta: NOKetiqueta: R 9.1

    Problema

    Existem duas modais dos cookies que quando abrem, não recebem logo o foco nos elementos da modal.

    Image

    Figura 1 - Modal que abre a partir do link"Abrir os cookies" do rodapé

    Image

    Figura 2 - Modal dos Cookies quando se entra pela primeira vez no site.

    Além disso, a modal de cookies apresentada no primeiro acesso ao site apenas recebe foco após a secção de Acessos Rápidos da página inicial, por se encontrar posicionada no meio do conteúdo no código HTML.

    Resolução

    • Devem rever as modais para garantir que estão estruturadas com role="dialog" e que possuem o atributo aria-modal="true", de forma a isolar o foco dentro da modal e impedir a interação com o conteúdo subjacente.

    • Devem garantir que .focus() é chamado quando a modal é aberta.

    • O foco deve ir para o primeiro elemento da modal (ex: botão de "Fechar" na modal que abre a partir do link do rodapé) ou ação principal (ex: botão "Aceitar todas" da modal que abre na primeira visita ao site).

    • Devem garantir que a modal dos Cookies quando se entra pela primeira vez é o primeiro elemento na página HTML a ser lido quando se entra no site e se navega pelas páginas.

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

etiqueta: NOK

Lista de evidências recolhidas:

  • evidência: issue #19 R 9.2 - Quando a modal está aberta, a navegação com teclado não fica circunscrita aos elementos que compõem modal

    etiqueta: chk 10 webetiqueta: NOKetiqueta: R 9.2

    Problema

    Quando se entram em duas modais dos cookies que existem no site, a navegação com teclado continua pelos elementos atrás da modal:

    Image

    Figura 1 -Foco encontra-se atrás da modal que abre a partir do link"Abrir os cookies" do rodapé

    Image

    Figura 2 - Foco encontra-se atrás da Modal dos Cookies quando se entra pela primeira vez no site.

    Resolução

    Quando uma modal é aberta, o foco do teclado deve ser automaticamente direcionado para dentro dela. Isto garante que os utilizadores que navegam com o teclado, incluindo aqueles que recorrem a tecnologias de apoio, possam interagir facilmente com o conteúdo apresentado e percebam que uma nova interação está disponível.

    • Devem rever as modais para garantir que estão estruturadas com role="dialog" e que possuem o atributo aria-modal="true", de forma a isolar o foco dentro da modal e impedir a interação com o conteúdo subjacente.

    • Devem garantir que .focus() é chamado quando a modal é aberta.

    • O foco deve ir para o primeiro elemento da modal (ex: botão de "Fechar" na modal que abre a partir do link do rodapé) ou ação principal (ex: botão "Aceitar todas" da modal que abre na primeira visita ao site).

    • Devem garantir que a modal dos Cookies quando se entra pela primeira vez é o primeiro elemento na página HTML a ser lido quando se entra no site e se navega pelas páginas.

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:

Checklist Conteúdo

etiqueta: NOK

Nível de conformidade:

  • Checklist Conteúdo: 81.3% (13/16)
    • Requisitos avaliados: 17 (1 N/A excluído, 16 aplicáveis)
    • Requisitos OK: 13
    • Requisitos NOK: 3
    • Requisitos N/A: 1

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:

  • evidência: issue #21 R 1.1 - O sítio Web não apresenta um resumo breve do seu propósito

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

    Problema

    Não existe qualquer resumo do propósito, pelo que deve ser adicionado.

    Image

    Figura 1 - Página inicial da CM Alcobaça

    Resolução

    Como referência de uma boa prática, é possível verificar no website acessibilidade.gov ou da Câmara Municipal de Valongo que o seu propósito está escrito no topo da página.

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

etiqueta: N/A

Lista de evidências recolhidas:

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:

  • evidência: issue #23 R 4.1 - Os documentos longos não têm um índice no topo com hiperligações internas para o mesmo

    etiqueta: chk conteúdoetiqueta: NOKetiqueta: R 4.1

    Problema

    Nas páginas consideradas longas, como a Exposições temporárias não existem um índice com hiperligações para cada secção interna dessa página.

    Image

    Figura 1 - Página Exposições temporárias é uma página longa.

    Resolução

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

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

etiqueta: NOK

Lista de evidências recolhidas:

  • evidência: issue #24 R 5.4 - Elementos gráficos interativos não aparentam ser clicáveis

    etiqueta: chk conteúdoetiqueta: NOKetiqueta: R 5.4

    Problema

    Na página inicial, há elementos interativos, como os cartões das Notícias, que têm um estilo não aparenta ser clicável, visto que a única indicação de que é clicável é seta em cima da imagem e o hover por cima do card.

    No entanto, quando se navega com teclado, o comportamento de focus não se manifesta mantendo-se o estilo normal.

    Image

    Figura 1 - Focus no primeiro card das Notícias não apresenta o estilo de focus

    Image

    Figura 2 - Hover no primeiro card das Notícias apresenta o estilo de focus

    Na páginas secundárias, como Cultura e Património e Publicações, as secções são clicáveis, mas não apresentam nenhuma indicação a não a linha acima do link mudar de cor e a mão em cima do link.

    Image

    Figura 3 - Links não têm indicação de que são clicáveis

    Resolução

    Rever o estilo dos elementos interativos para que seja mais perceptível que são clicáveis.

    Os elementos interativos devem ter um estilo que demonstre que são clicáveis e, ao mesmo tempo, suficientemente diferente de elementos não clicáveis para que não se confundam.

    Por exemplo, os elementos clicáveis terem sempre sombra ou a seta indicada nos vários elementos da página inicial.

Outras violações

etiqueta: NOK

Lista de evidências recolhidas:

  • evidência: issue #13 Outras melhorias - O texto alternativo das imagens não deve ser repetido em texto visível

    etiqueta: outras violaçõesetiqueta: NOK

    Problema

    Existem imagens com texto alternativo, o que por si é uma boa prática de acessibilidade a seguir.

    No entanto, esse texto alternativo das imagens também está presente visivelmente, resultando no leitor de ecrã a ler informação repetida e redundante, criando ruído na experiência.

    Image

    Figura 1 - Alcobaça e Vestiaria é o texto visível da imagem, mas também o texto alternativo no alt.

    O mesmo se aplica ao ícone da bandeira do país na combobox da mudança da língua, que tem o texto alternativo igual ao texto visível

    Image

    Figura 2 - Texto alternativo do ícone das bandeiras é igual ao texto visível da opção.

    Image

    Figura 3 - Texto alternativo é alt="generic image", o que está errado. Mas também não deve repetir o nome da freguesia.

    Image

    Figura 4 - Texto alternativo da imagem é "Marcas Identitárias, igual ao texto por baixo da imagem.

    Resolução

    Devem rever os atributos alts para que fiquem nulos, ou seja, alt="". Desta forma, o leitor de ecrã irá ignorar a imagem decorativa. Neste caso, a imagem é considerada decorativa porque não adiciona informação relevante, uma vez que já é transmitida pelo texto visível.

    Nota: Existem muitas páginas com imagens decorativas com texto alternativo igual ao texto visível, sendo uma prática geral no site.

    Podem encontrar algumas dessas imagens decorativas a rever nas seguintes páginas, havendo outras a rever:
    https://www.cm-alcobaca.pt
    https://www.cm-alcobaca.pt/49542/conhecer
    https://www.cm-alcobaca.pt/49543/area-do-municipe
    https://www.cm-alcobaca.pt/49544/municipio
    https://www.cm-alcobaca.pt/49547/camara-municipal
    https://www.cm-alcobaca.pt/49548/assembleia-municipal
    https://www.cm-alcobaca.pt/49549/freguesias

Significado das etiquetas utilizadas