Relatório Avaliação da Candidatura da Câmara Municipal do Barreiro

Avaliação feita por: ARTE. I.P. - Núcleo de Experiência e Usabilidade
Data de criação: 03/06/2025
Última atualização: 12/09/2025
URL: https://www.cm-barreiro.pt
Propriedade: CM Barreiro
Candidatura: Bronze
Progresso (% de requisitos auditados): 100%

Introdução

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

Estado das avaliações efetuadas
Tipo de avaliação	Estado
Avaliação Automática	etiqueta: NOK
Avaliação Manual	etiqueta: NOK

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

Níveis de conformidade das avaliações manuais
Checklist	Conformidade alcançada	Resultado
10 aspetos	42.3% (11/26)	etiqueta: Não passa
Conteúdo	58.8% (10/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.

Declaração de Acessibilidade

etiqueta: OK

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:

evidência: Declaração de acessibilidade está no formato machine readable

etiqueta: OKetiqueta: dec a11y

A declaração de acessibilidade está no formato machine-readable.

Gerador da Declaração de Acessibilidade preenche os campos automaticamente ao inserir a url

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:

evidência: Páginas que não ultrapassam o score de 9 pontos

etiqueta: av autoetiqueta: NOK

Para obter o Selo de Usabilidade e Acessibilidade, os sítios web devem apresentar todas as páginas com valores a partir de 9.
No caso da CM Barreiro foi localizada 1 página na amostra com valores abaixo de 9 pontos:
https://www.cm-barreiro.pt/conhecer/agenda-de-eventos/51-anos-do-25-de-abril/
evidência: Avaliação automática - Access Monitor / Observatório

etiqueta: av autoetiqueta: NOK

Analisámos a amostra com o Access Monitor, de acordo com o método Home+, e obteve-se, no total, 590 páginas. Destas, 59 páginas (10%) não cumprem os testes de conformidade ‘AA’ da WCAG.

Resultados da amostra do site da CM Barreiro no Observatório Português da Acessibilidade Web
evidência: Avaliação automática - Rocket Validator

etiqueta: av autoetiqueta: NOK

Efetuámos também uma análise com o validador Rocket Validator que revela a existência de 8314 erros e 388 avisos de Acessibilidade. Para mais informações partilhamos o relatório da análise automática feita com o Rocket Validator

Avaliação manual

etiqueta: NOK

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

checklist 10 aspetos críticos de acessibilidade funcional;
checklist Conteúdo (se candidato a Selo Bronze);

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: 42.3% (11/26)
- Requisitos avaliados: 27 (1 N/A excluído, 26 aplicáveis)
- Requisitos OK: 11
- Requisitos NOK: 15
- Requisitos N/A: 1

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: Há opções do menu que não estão estruturadas como lista (elementos "ul" e "li")

etiqueta: chk 10 webetiqueta: NOKetiqueta: R 1.1
O menu de navegação deve estar estruturado como uma lista de opções.
- Ver requisito 1.1 da lista 10 aspetos
Verificámos que as opções presentes nos menus do rodapé do website não estão estruturadas como lista ul li, nomeadamente:
- O menu com os links úteis.
- O menu com a indicação das redes sociais do website.
Secção links úteis no rodapé da página

Secção de links para redes sociais no rodapé da página

Para que a navegação seja acessível e corretamente interpretada pelas tecnologias de apoio, os elementos dos menus e submenus deverão estar todos estruturados como listas, recorrendo aos elementos ul e li.
Recomendamos que os menus referidos acima sejam estruturados como listas, utilizando tags ul e li.

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

etiqueta: NOK

Lista de evidências recolhidas:

evidência: Impossibilidade de aceder à página destino dos links de itens de menu que contenham subopções

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.
- Ver requisito 1.2 da lista 10 aspetos
Verificámos que não existe forma de aceder, via teclado, às páginas de destino das hiperligações associadas aos itens do menu principal que contêm subopções.
Eis o comportamento das teclas relevantes:
– As teclas seta para a direita e seta para a esquerda expandem e colapsam os itens de menu com subopções.
– As teclas Enter e Espaço também expandem esses itens.
– As teclas Tab e Shift+Tab permitem a navegação entre todas as opções do menu que estejam visíveis ou expandidas.
No entanto, não existe qualquer forma de navegar diretamente para as páginas cujos URLs estão associados aos itens de menu com subopções.

Figura 1 - Opções de primeiro nível do menu não são acessíveis pelo teclado

Recomendamos a reestruturação do menu principal de forma a contemplar esta funcionalidade. Uma possível solução consiste na introdução de uma ligação separada para cada item de menu pai que contenha subopções. Neste tutorial da W3C é apresentada uma explicação pormenorizada desta solução.
evidência: Teclas de navegação não correspondem ao mapa mental estabelecido

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.
- Ver requisito 1.2 da lista 10 aspetos
Verificámos que, na versão desktop do menu principal, as teclas para expansão e colapso das opções de menu estão trocadas.
Com efeito, é utilizada a seta para a esquerda para expandir as opções de um item de menu e a seta direita para as colapsar, sendo este processo contrário à utilização comum deste tipo de tarefa.

Menu com teclas de atalho invertidas ou mal implementadas

Recomendamos que sejam trocadas as funções destas duas teclas, de modo a fazê-las corresponder ao seu uso intuitivo.
Verificámos ainda, na versão desktop do menu principal, que as teclas “seta para baixo” e “seta para cima” não apresentam um comportamento consistente ao atingir, respetivamente, o final e o início da lista de opções do menu. Quando o foco está no último item e se prime a tecla “seta para baixo”, nenhuma ação é executada. Em contraste, ao premir a tecla “seta para cima” no primeiro item, o foco move-se para o último item da lista.
Esta assimetria de comportamento é considerada incoerente.
Recomenda-se a uniformização do comportamento das teclas de navegação, garantindo que ambas realizem a mesma ação — seja inatividade ou rotação circular — quando acionadas nos limites superior e inferior do menu.

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

etiqueta: N/A

Lista de evidências recolhidas:

evidência: O requisito foi avaliado como “Sim”, mas é “Não Aplicável”

etiqueta: chk 10 webetiqueta: N/Aetiqueta: R 1.3
As imagem-link, caso existam no menu, devem ter o correspondente equivalente alternativo em texto.
- Ver requisito 1.3 da lista 10 aspetos
Verificou-se que não existem imagens-link no menu. Quando o website não possui elementos mencionados pelo requisito, então o requisito será considerado como “Não Aplicável”.

É necessário remover as evidências associadas a este requisito 1.3 da checklist dos 10 aspectos e a sua atualização para “Não Aplicável” na checklist.

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:

evidência: Existem cabeçalhos mal atribuídos

etiqueta: chk 10 webetiqueta: NOKetiqueta: R 2.2

Existe uma marcação hierarquizada de títulos e subtítulos na página <h1>...<h6>.
– ver requisito 2.2 na lista 10 aspetos

Nas páginas 51 anos do 25 de Abril, NOVA DATA | Forum Barreiro Night Run 2025, Processo Desmaterialização
e Serviço de Atendimento e Acompanhamento Social existem subtítulos que embora visualmente estejam destacados como negrito eles estão sendo estruturados como textos dentro de divs

'Data' e 'Local' estruturados como textos ao invés de serem cabeçalhos na página NOVA DATA | Forum Barreiro Night Run 2025

Dias dos eventos estão estruturados como textos ao invés de serem cabeçalhos na página 51 anos do 25 de Abril

O nome dos eventos estão sendo estruturados como h2ao invés de serem h3 na página 51 anos do 25 de Abril

'Entrega de processos em formato digital', 'Saiba como fazer' e 'Como entregar processos:' estão estruturados como texto ao invés de serem cabeçalhos h2, h3, h3 respectivamente

Recomendamos rever de modo geral o website para garantir que os textos muitas vezes destacados em negrito ou outro elemento visual, se transmitem uma organização lógica do conteúdo, devem ser estruturados como cabeçalhos.
evidência: Existe salto na hierarquia de cabeçalhos

etiqueta: chk 10 webetiqueta: NOKetiqueta: R 2.2
Existe uma marcação hierarquizada de títulos e subtítulos na página <h1>...<h6>.
– ver requisito 2.2 na lista 10 aspetos

Nas páginas Cartão Barreiro vertente cheque cultura disponível | Cultura para todos à distância de um clique e Visite os nossos Mercados Municipais existe um salto na hierarquia dos cabeçalhos, nomeadamente do h1 para h5 e do h1 para h3, respetivamente.

Salto na hierarquia do cabeçalho h1 para h3 na página Visite os nossos Mercados Municipais

Salto na hierarquia do cabeçalho h1 para h5 na página Cartão Barreiro vertente cheque cultura disponível | Cultura para todos à distância de um clique

Recomendamos rever as páginas do website para garantir que respeitem a hierarquia de títulos e subtítulos, o que implica:
- Ter 1 título h1 (que marca o texto que representa o título da página ou, no caso da Homepage, o logo da entidade);
- Ter as várias secções do documento marcadas com h2;
- Ter as várias subseções de h2 marcadas com h3, as subsecções destas com h4 e assim hierarquicamente encadeados até h6;
- Evitar ter elementos de hierarquia inferior sem um elemento de hierarquia imediatamente superior (subseções órfãs). Por exemplo, ter um h3 sem a correspondente h2, ou h4 sem a correspondente h3.
evidência: Existem cabeçalhos em branco

etiqueta: chk 10 webetiqueta: NOKetiqueta: R 2.2

Existe uma marcação hierarquizada de títulos e subtítulos na página <h1>...<h6>.
– ver requisito 2.2 na lista 10 aspetos

Nas páginas Processo Desmaterialização, Serviço de Atendimento e Acompanhamento Social, NOVA DATA | Forum Barreiro Night Run 2025 e 51 anos do 25 de Abril existem cabeçalhos h2 que estão em branco.

Cabeçalho h2 vazio na página de Serviço de Atendimento e Acompanhamento Social

Recomendamos reverem as páginas para garantir que não existem cabeçalhos estruturados no HTML e que estão em branco.
evidência: Existem títulos que não estão estruturados como cabeçalhos

etiqueta: chk 10 webetiqueta: NOKetiqueta: R 2.2

Existe uma marcação hierarquizada de títulos e subtítulos na página <h1>...<h6>.
– ver requisito 2.2 na lista 10 aspetos

Os utilizadores de leitores de ecrã apenas conseguem perceber as secções “Links Úteis” e “Contactos”, no rodapé do site, devido à diferença no tamanho da letra desses elementos.

Figure 1 - Secções "Links Úteis" e "Contactos" presentes no rodapé, sem marcação com elementos cabeçalho

Com efeito, estes elementos não possuem nenhuma indicação semântica que permita transmitir aos leitores de ecrã que os mesmos marcam o início de secção, não sendo portanto possível aos utilizadores destas tecnologias a navegação entre estas secções de forma rápida.
Pelo exposto, recomendamos que os textos “Links Úteis” e “Contactos”, presentes no rodapé do site, sejam colocados em elementos de cabeçalho nível 2 (<h2>), de forma a possibilitar a sua descoberta através de teclas rápidas de navegação dos leitores de ecrã, permitindo assim uma navegação mais rápida entre estas secções.
Existem outras páginas que contêm textos de início de secção que não estão marcados como cabeçalhos. Eis algumas delas:
Executivo Camarario - Contém textos com letra maior ou em negrito que não estão marcados como cabeçalhos (figura 2).
Competências e Estrutura Orgânica – Contém acordeons cujos títulos correspondem a secções, mas não estão marcados como cabeçalhos (figura 3).

Figura 2 - Página "Executivo camarário" com elementos com letra maior ou a negrito sem marcação com elementos cabeçalho

Figura 3 - Exemplo de um dos acordeons da página "Competências e Estrutura Orgânica" cujo título não está marcado como cabeçalho

No caso da página Executivo Camarario, recomendamos que os textos correspondentes aos cargos do executivo (presidente e os vários vereadores) sejam marcados com elementos cabeçalho de nível 2 (<h2>), e os textos "Atendimento" e "Morada" de cada cargo sejam marcados com elementos de cabeçalho de nível 3 (<h3>).
No caso da página Competências e Estrutura Orgânica, os títulos dos acordeons devem ser marcados com elementos cabeçalho de nível 2 (<h2>).
evidência: Texto de cabeçalho incorretamente definido

etiqueta: chk 10 webetiqueta: NOKetiqueta: R 2.2

Existe uma marcação hierarquizada de títulos e subtítulos na página <h1>...<h6>.
– ver requisito 2.2 na lista 10 aspetos

Verificámos que na página Livro de Reclamações Electrónico e Resolução Alternativa de Litígios Existe um cabeçalho cujo texto não se encontra corretamente definido.

Figura 1 - Texto de cabeçalho incorretamente definido

Como se pode observar na figura, o texto que foi atribuído ao cabeçalho de nível 2 corresponde a um texto de um parágrafo e não ao de um título.
Recomendamos a alteração do texto atribuído ao cabeçalho de nível 2 para “Canal de Denúncias”, e a colocação do texto antes atribuído ao <h2> num elemento <p> abaixo desse <h2>. Devem procurar todos os cabeçalhos cujos textos não representem títulos ou subtítulos e corrigi-los à semelhança do exemplo aqui indicado.

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: Existem campos sem etiqueta

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

O campo 'Inserir termo' da página Conselho Municipal de Juventude não possui etiqueta associada ao campo, e por consequência, também não possui uma etiqueta visível junto ao campo.

O campo 'Inserir termo' não possui etiqueta associada e que seja visível junto ao campo

Recomendamos reverem todo os campos de preenchimento do website para garantir que tenham uma etiqueta associada e que esteja visível junto ao seu respetivo campo. Para isso, é necessário que:
- A etiqueta do campo deve ser estruturada como um elemento e deve estar associada ao campo.
- Para associar ao campo, o for da legenda e o id do campo de input devem ser iguais.
Um exemplo de estrutura seria:
```
<label for="firstname">Primeiro nome:</label>
<input type="text" name="first" id="firstname">
```
ou
```
<label>
    Primeiro nome:
    <input type="text" name="firstname">
</label>
```
Identificámos as seguintes páginas com o mesmo problema:
evidência: Atributos de campos de formulário de uso dispensável

etiqueta: chk 10 webetiqueta: melhoriaetiqueta: R 4.1

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

Existem atributos de campos de formulário cujo uso é dispensável.

Figura 1 - Campo <input>` de pesquisa com atributos placeholder e aria-label que tem uma etiqueta associada programaticamente

Como se pode observar na figura, o formulário de pesquisa contém um elemento <input> com os atributos placeholder e aria-label, ambos com o mesmo valor: "Introduza termo de procura".
O atributo placeholder não é recomendável, uma vez que o seu conteúdo desaparece da interface assim que se começa a escrever no campo, o que pode ser prejudicial para utilizadores com défice de memória.
O texto presente no atributo aria-label não é visível no ecrã, mas pode ser útil para utilizadores de tecnologias de apoio, ao reforçar a informação apresentada no placeholder.
No entanto, constatámos que este campo <input> já possui uma etiqueta programaticamente associada (elemento <label>) com o texto "Procurar". Neste contexto, os atributos placeholder e aria-label tornam-se redundantes.

Dado que o elemento <label> está corretamente associado ao campo, consideramos que o respetivo texto deve ser utilizado como nome acessível. Recomenda-se, por conseguinte, a remoção dos atributos placeholder e aria-label do campo <input>.
evidência: Campos sem etiquetas

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

Os campos “Tipo de conteúdo”, “Escolha o ano” e “Escolha o mês” presentes no formulário de pesquisa não têm etiquetas associadas programaticamente.

Figure 1 - campos do formulário de pesquisa sem etiquetas associadas

O texto “Tipo de Conteúdo” presente no elemento <div> próximo ao campo com essa função é apresentado visualmente e aos leitores de ecrã, mas não está associado programaticamente ao campo, o mesmo se passando com o texto “Filtros”.

Segue abaixo um exemplo alternativo de correção, em que se associa programaticamente uma legenda ao campo de pesquisa e se remove o atributo aria-label do campo “Tipo de Conteúdo” considerado para ilustração:

Exemplo:
```
<label for="search-filter-categories">Tipo de Conteúdo</label>
<select id="search-filter-categories" class="search-001__form-select-cat Body_2PrimaryNeutralLeft" name="post_type" form="searchform">
<option value="" selected="">Selecionar</option>
<option value="eventos">Eventos</option>
</select>
```
Recomendamos que sejam revistos todos os formulários e sejam adicionadas legendas utilizando elementos <label>, associando-as aos campos respetivos, de acordo com os exemplos referidos.

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

etiqueta: NOK

Lista de evidências recolhidas:

evidência: Existe um campo que não está estruturado como obrigatório

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

Na página Gabinete de Desenvolvimento Económico existe um formulário cujo campo 'Privacidade' que não está programaticamente estruturado como obrigatório.

Campo de privacidade não está estruturado como obrigatório

Para que o campo seja identificado como obrigatório, é possível estruturar de duas formas:
- Se utilizar o atributo de HTML5 required, ou seja, <input .... required> ou
- Se utilizar o atributo aria-required, ou seja, <input ... aria-required="true">,

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

etiqueta: NOK

Lista de evidências recolhidas:

evidência: Imagens link sem texto alternativo

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

As imagens link de redes sociais e partilha de conteúdo, presentes em cada notícia do sítio web, não possuem texto alternativo.

Figura 1 - Notícia Fraca qualidade do ar registada a 30 de junho 2025 links de redes sociais facebook, twitter, whatsapp e email sem descrições textuais alternativas

Recomendamos a inserção de texto alternativo em todas as imagens link presentes no site. Neste caso, um exemplo de correção para a imagem link associada ao facebook pode passar pela inserção do atributo aria-label ao elemento <i>, da seguinte forma:
<i aria-label = "Facebook" class="fab fa-facebook-f"></i>

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:

evidência: Existem textos com contraste abaixo do recomendado no estado hover

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

Quando passamos o rato nas opções do menu principal a cor laranja #F15924 apresentada no :hover possui contraste abaixo do recomendado (3,4:1)

Opções do menu estão com contraste abaixo do recomendado no estado :hover

Isso acontece em outros locais, como por exemplo, nos breadcrumbs, título das notícias da homepage, e botões interativos

Texto do breadcrumb possui contraste abaixo do recomendado no estado :hover

Título das notícias possui contraste abaixo do recomendado no estado :hover

Recomendamos rever de modo geral os elementos interativos do website para garantir que o texto tenha contraste com a cor de fundo também nos diferentes estados (:hover, :focus)
evidência: O texto 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

Na página de Proteção Civil existem textos com pouco contraste.

Bloco de texto com contraste abaixo do recomendado (3,13:1)

Na página Em vigor os textos também estão com pouco contraste

Bloco de texto com contraste abaixo do recomendado (3,4:1)

Recomendamos rever de modo geral o website principalmente os pares de cores #8A8A8A com #F4F4F4, #838383 com #F4F4F4 #8A8A8A e #F4F4F4 com fundo branco #FFFFFF para garantir que todos os blocos de texto tenham contraste, de no mínimo, 4:1 com a cor de fundo.

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:

evidência: vídeos com mensagens eminentemente visuais sem audiodescrição ou transcrição descritiva

etiqueta: chk 10 webetiqueta: NOKetiqueta: R 7.2

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

A página Piscinas Municipais contém um vídeo com mensagens eminentemente visuais que não possui uma audiodescrição ou transcrição descritiva.
As legendas e transcrição existentes são automáticas e não contêm uma descrição das cenas visuais que ocorrem no vídeo.

Figura 1 - transcrição do vídeo "Inscrições abertas para as Piscinas Municipais"

Como se pode observar na figura, a transcrição do vídeo apenas contém expressões como “Music” e “Applause” que em nada contribuem para a descrição das mensagens visuais veiculadas.
Recomendamos a utilização de legendas e transcrições descritivas em todos os vídeos com mensagens eminentemente visuais presentes no website, de forma a garantir que os utilizadores conseguem compreender o conteúdo desses vídeos. Para tal, podem ser substituídas as legendas já existentes por uma versão que contenha a descrição textual das cenas visuais, sendo que essa versão das legendas pode também substituir a transcrição existente.

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

etiqueta: NOK

Lista de evidências recolhidas:

evidência: R 8.2 - 10 Aspetos- Existem conteúdos que estão visíveis apenas para tecnologias de apoio

etiqueta: chk 10 webetiqueta: NOKetiqueta: R 8.2

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

Ao navegar com leitor de ecrã pelas opções no topo da página, poderão ser identificados dois elementos distintos: a seleção de idioma e um link para o Tradutor do Google. Visualmente, apenas a seleção de idioma está disponível. A opção do tradutor encontra-se fora de contexto e está acessível unicamente através da navegação por leitor de ecrã.

Leitor de ecrã identifica opção de seleção de idiomas

Leitor de ecrã identifica o tradutor do Google

Ao desligar CSS é possível ver que estruturalmente existe um link tradutor do Google e que está visível para o leitor de ecrã

Quando se retira o CSS é possível identificar, no topo de todas as páginas do site, um link (cujo texto é “Accessibility by WAH”) que é escondido visualmente pelo CSS e é visível para as tecnologias de apoio.

Figura 1 - Link escondido visualmente pelo CSS mas visível para as tecnologias de apoio

O carrossel que apresenta os destaques, presente na página inicial, mostra visualmente um item de cada vez. No entanto, os utilizadores de leitores de ecrã conseguem visualizar todos os itens do carrossel.

Figura 2 - Carrossel com apresentação de destaques apresenta todos os itens aos utilizadores de leitores de ecrã

Tal configuração, para além de provocar uma incoerência entre o que é mostrado visualmente e o que é mostrado aos leitores de ecrã, obriga a que os utilizadores destas tecnologias tenham de passar por mais informação antes de chegarem ao próximo componente da página, tornando a navegação menos eficiente.

Nesta página com exemplos de carrosséis do W3C encontram boas práticas para a construção de carrosséis acessíveis, que podem ser usadas na adaptação deste componente.

Para garantir uma experiência de navegação mais acessível e consistente, recomendamos que seja feita uma revisão geral da estrutura do código HTML por forma a garantir coerência entre o conteúdo visual da página e a sua organização semântica, criando desta forma uma experiência de navegação mais clara e coerente para utilizadores de tecnologias de apoio.

Recomendamos rever a estrutura HTML do website com o CSS desativado para garantir que o conteúdo quando desligado o CSS seja o mesmo apresentado na interface visualmente com o CSS ativo.

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:

evidência: As legendas estão sendo utilizadas de forma inapropriada

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

Na página Gabinete de Desenvolvimento Económico, os campos do formulário apresentam as seguintes legendas: "Nome do/a Responsável", "Nome da Empresa" e "Privacidade", que estão sendo apresentadas visualmente como etiquetas principais de cada campo.

Esta estrutura está incorreta, uma vez que as legendas (utilizadas com o elemento fieldset) têm como objetivo agrupar campos em comum e nesse formulário existe uma legenda e fieldset para cada um desses campos. Além disso, as etiquetas label tem como objetivo indicar o que deve ser preenchido e é possível identificar que a label não está apropriada.

Campos 'Nome do/a Responsável', 'Nome da Empresa' e 'Privacidade' estão sendo estruturados com o fieldset e legend. As labels 'Primeiro', 'Último' e 'Empresa' não estão nomeados apropriadamente

Recomendações de ajustes nos campos do formulário:
- Campo "Empresa": recomendamos a remoção das tags legend e fieldset. A etiqueta (label) deverá ser renomeada para "Nome da Empresa (Obrigatório)"
- Campos "Primeiro" e "Último": recomendamos manter as tags fieldset e legend, contudo, o indicativo de que é obrigatório deve ser inserido nas etiquetas (label) de cada campo. Assim, sugerimos renomear para: "Primeiro nome (obrigatório)" e "Último nome (obrigatório)"
  Alternativamente, poderá ser considerada a remoção das tags legend e fieldset, unificando os dois campos num só, com a seguinte etiqueta: "Nome do/a Responsável (Obrigatório)"
- Campo de "Privacidade": recomendamos a remoção das tags legend e fieldset, mantendo a informação estruturada apenas como texto, com o seguinte conteúdo: "Privacidade (Obrigatório)"
evidência: Uso de listas de forma inapropriada

etiqueta: chk 10 webetiqueta: NOKetiqueta: R 8.3

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

A secção “Reuniões de Câmara | Últimos documentos” presente na página inicial contém oito documentos, que para efeitos visuais foram distribuídos em duas listas <ul>.

Figura 1 - Duas listas não ordenadas, cada uma contendo quatro documentos (para exemplificação apenas o primeiro item da primeira lista está expandido)

Semanticamente, o que faz sentido é a agregação dos oito documentos numa única lista, até porque não parece haver nenhuma característica que seja diferente nos documentos de uma e de outra lista que legitime esta desagregação. O único ponto em que esta divisão se baseia parece ser a maior facilidade de disposição visual dos documentos no ecrã que esta estruturação possibilita.
No entanto, elementos estruturais não devem ser confundidos com elementos de estilo. Neste caso em particular, a existência destas duas listas faz com que não seja fornecido aos utilizadores de leitores de ecrã o número total de documentos (são anunciadas duas listas com quatro documentos, uma a seguir à outra), o que não possibilita uma navegação tão eficiente.
Pelo exposto, recomendamos a colocação de todos os documentos numa única lista e a definição de estilos CSS que permitam dispor os vários itens no ecrã de acordo com o pretendido, permitindo assim a separação entre a estrutura e o estilo.
evidência: Acordeons implementados com atributos inadequados

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

Os acordeons encaixados presentes na página Reuniões foram desenvolvidos recorrendo a alguns atributos inadequados, o que prejudica a acessibilidade destes acordeons por parte de quem utiliza o teclado e/ou tecnologias de apoio.

Figura 1 - Exemplo de acordeons encaixados utilizando atributos inadequados na sua construção

Segue a lista de atributos inadequados, apresentados na figura:
- Role = “tab” nos itens de lista (<li>)
- Role = “tablist” e aria-multiselectable = “true” na lista de itens externa (<ul>)
- Role = “group” nas listas de itens internas (<ul>)
- Role = “menuitem” nas ligações apresentadas nos painéis de acordeon mais internos.
  O atributo aria-multiselectable = “true” é inadequado em acordeons, já que não estamos perante listas de múltipla seleção.
  O atributo role = “menuitem” também é inadequado, já que não estamos perante itens de menu.
  O acordeon foi construído com uma estrutura personalizada, utilizando role = “tablist” e role = “tab”. Por omissão, os elementos <li> não são focáveis, apesar de o role = “tab” lhes atribuir a semântica de separadores. Tal significa que não é possível navegar pelos vários itens dos painéis dos acordeons utilizando o teclado (tab e shift+tab).
  Para além disso, esta combinação de atributos causa problemas de acessibilidade difíceis de depurar.
  Com efeito, para além de não ser possível focar os vários itens dos painéis via teclado, o leitor de ecrã utilizado no teste (NVDA) anuncia toda a cadeia de itens expandidos até ao item atual.
  Por exemplo: se expandirmos o ano de 2025 e navegarmos para a lista de reuniões, este leitor de ecrã anuncia a seguinte informação:
  “Separador expandido separador recolhido item de menu 17 – Reunião de Câmara Ordinária Publica | 02 de julho de 2025”
  “Separador expandido separador recolhido item de menu 16 – Reunião de Câmara Ordinária Publica | 18 de junho de 2025”
  Etc.
  Quando devia anunciar apenas
  “17 – Reunião de Câmara Ordinária Publica | 02 de julho de 2025”
  “16 – Reunião de Câmara Ordinária Publica | 18 de junho de 2025”
  Etc.
  Ao expandir o item “17 – Reunião de Câmara Ordinária Publica | 02 de julho de 2025” e navegar no painel interno, o anúncio é o seguinte:
  ““Separador expandido separador expandido separador item de menu Edital nº 314/2025 – Edital de Publicitação da Reunião Ordinária Publica de 02/07/2025...”
  Como deverá ser fácil de compreender, esta verbosidade no anúncio de cada elemento dos painéis interiores contribui para uma navegação menos eficiente por parte de quem utiliza leitores de ecrã.
  Recomendamos a restruturação do acordeon utilizando uma estrutura mais simples, com o número mínimo de atributos necessários ao bom funcionamento de um acordeon.
  Essa estrutura passa pela utilização de elementos <div> para os painéis dos acordeons, e de botões para os itens cujas ações provocam a visualização e ocultação dos painéis.
  No que diz respeito aos atributos associados aos acordeons, recomendamos a utilização dos seguintes, nos elementos <button>:
- aria-expanded, com o valor “true” caso o respetivo painel esteja expandido, “false” caso contrário;
- aria-controls, com o valor "ID-painel", que referencia o id do painel do acordeon que o botão controla.
  Por último, salientamos que os textos descritivos dos botões são considerados títulos de secção, pelo que os botões devem ser colocados em elementos cabeçalho.
  Neste caso, os botões que controlam os acordeons exteriores devem ser colocados em elementos <h2>, e os botões que controlam os acordeons interiores devem ser colocados em elementos <h3>.
  Para obtenção de informação mais detalhada acerca da construção correta de acordeons, recomendamos a consulta de um exemplo de acordeon na página do W3C.
  Recomendamos ainda a visualização da página de exemplo de acordion aninhado, que adapta parte da estrutura do acordeon em apreço, com todas as recomendações indicadas acima, podendo por isso constituir um material de apoio na restruturação do componente.

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: O foco não é direcionado para dentro da modal

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

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.

A secção “Barreiro TV” da página inicial contém links para vídeos. Cada um desses links provoca a abertura de uma modal ao ser acedido. No entanto, o foco não é direcionado para o conteúdo de nenhuma modal.

Figura 1 - Ao abrir um vídeo com o leitor de ecrã o foco não é direcionado para dentro da modal

Recomendamos ajustar o foco para que, ao abrir a modal, o cursor seja automaticamente direcionado para o primeiro campo da modal. Isso deve ser revisto em todos os vídeos presentes na secção “Barreiro TV” da página inicial do website.

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: O foco não está limitado à modal do player de vídeo

etiqueta: chk 10 webetiqueta: NOKetiqueta: R 9.2

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

Manter o foco do teclado dentro da caixa de diálogo garante que os utilizadores possam interagir com o seu conteúdo sem distrações de outros elementos na página. Este controlo do foco facilita a navegação, ajudando os utilizadores a compreenderem a sua posição na interface.
Quando um vídeo da secção “Barreiro TV” da página inicial é acedido, é possível percorrer o restante conteúdo que rodeia a modal com o player.

Figura 1 - Leitor de ecrã lê o restante do conteúdo da página com a modal do player de vídeo aberta

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

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

etiqueta: NOK

Lista de evidências recolhidas:

evidência: Botões de fecho das modais não estão acessíveis com leitor de ecrã e teclado

etiqueta: chk 10 webetiqueta: NOKetiqueta: R 9.3

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

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

Os botões de fecho de todas as modais dos vídeos da secção “Barreiro TV” da página inicial são controlos personalizados, implementados com o elemento div, em vez de controlos nativos do HTML, como o elemento button (figura 1)

Figura 1 - Botão de fecho de uma modal implementado com um elemento div

No que respeita à acessibilidade total de um botão, este tipo de personalização exige muitos mais ajustes do que um controlo nativo, que já é acessível por omissão.

Neste exemplo, os botões de fecho das modais não recebem o foco via teclado (tab e shift+tab) com o leitor de ecrã ativado. Para além disso, também não é possível fechá-las utilizando a tecla ‘Esc’.

Recomendamos que todas as modais incluam um botão “Fechar”, devidamente rotulado e claramente visível. Preferencialmente, a modal também deve fechar pela tecla “ESC”.

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:

evidência: O foco é perdido quando a janela modal é fechada

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

Garantir que o foco retorne ao elemento que acionou a modal é uma prática que beneficia especialmente pessoas que utilizam navegação por teclado ou leitores de ecrã, ajudando-as a manter-se orientadas dentro da interface.

Ao fechar uma modal, se o foco é perdido ou deslocado para um local inesperado, os utilizadores precisarão percorrer novamente a interface até chegar no local desejado para continuar a interação desejada.

Os botões de fecho de todas as modais dos vídeos da secção “Barreiro TV” da página inicial não são focáveis via teclado (tab e shift+tab). Por seu turno, a tecla ‘esc’ apenas fecha a modal quando o leitor de ecrã está desativado, e nessa situação o foco volta para o elemento que invocou a modal. No entanto, estamos perante um comportamento inconsistente, cujo resultado nunca é de sucesso se o leitor de ecrã estiver ativado.

Recomendamos a revisão do comportamento dos botões de fecho das modais indicadas acima, garantindo que, quando acionados via teclado, o foco é corretamente devolvido ao elemento que invocou a respetiva modal — independentemente de estar, ou não, a ser utilizado um leitor de ecrã. O mesmo comportamento consistente deve ser atribuído à tecla 'Esc'.

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

etiqueta: NOK

Lista de evidências recolhidas:

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

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

Foram encontrados ficheiros em formato PDF em que não é possível extrair os conteúdos.
Eis alguns documentos em que tal acontece:
- Os documentos presentes na página Atas, por exemplo, o documento Ata nº 006/2024
- Alguns documentos complexos presentes na página Mapa de Pessoal, por exemplo, o documento Lista Nominativa de Transição das carreiras de Informática. Este último documento contém uma tabela cuja estrutura se perde quando o texto é extraído.
  Devem garantir que os ficheiros PDF são otimizados para que seja possível extrair a informação para um processador de texto. Desta forma, garante-se que o texto pode ser lido por leitores de ecrã na ordem correta. No caso de documentos que são fotocópias, contendo apenas imagens, é possível converter os documentos para texto através do Reconhecimento Óptico de Caracteres (OCR) da Adobe.

Checklist Conteúdo

etiqueta: NOK

Nível de conformidade:

Checklist Conteúdo: 58.8% (10/17)
- Requisitos avaliados: 17 (17 aplicáveis)
- Requisitos OK: 10
- Requisitos NOK: 7

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: Resumo do propósito do site na homepage não visível em todas as resoluções, sem fazer scroll

etiqueta: chk conteúdoetiqueta: NOKetiqueta: R 1.1

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

Na Homepage deve existir uma breve descrição do propósito do website que demonstre que tarefas é possível realizar no mesmo. Esse propósito deve ser imediatamente visível na página, sem ser necessário fazer scroll, avançar no slideshow, entre outros.

O resumo do propósito na Homepage da CM Barreiro não é visível em todas as resoluções, sem fazer scroll.

Resolução mobile da homepage, em que é necessário fazer scroll para visualizar o propósito do sítio web

Para garantir que a mensagem seja visível antes de fazer scroll, recomendamos que a mesma seja apresentada no topo da página. Tal alteração, no caso desta homepage que tem uma enorme densidade de informação, também irá favorecer os utilizadores de leitores de ecrã, que passarão a percecionar a mensagem no primeiro contacto com a página.

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

Exemplo de propósito do website acessibilidade.gov

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

etiqueta: NOK

Lista de evidências recolhidas:

evidência: Não está explícito onde é possível localizar o glossário

etiqueta: chk conteúdoetiqueta: NOKetiqueta: R 1.2

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

Aproveitamos para salientar que o glossário, maioritariamente de siglas, colocado nas evidências, não se encontra referenciado num local visível ou comum do sítio web (por exemplo, no rodapé), pelo que os utilizadores não tomam conhecimento da sua existência.

Verificámos também que existem termos e siglas que estão misturadas junto com termos complexos do glossário.

"Aqui Barreiro" está sendo apresentado no meio das siglas do glossário

Pelo exposto, recomendamos a inserção de uma hiperligação para o glossário numa área visível ou comum do sítio web e separar as siglas e palavras incomuns no glossário de forma a facilitar a procura da informação.

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:

evidência: O corpo de texto tem um tamanho inferior ao recomendado (16 pixeis)

etiqueta: chk conteúdoetiqueta: NOKetiqueta: R 2.1

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

Na página Cartão Barreiro o tamanho dos textos está abaixo do recomendado (14 pixels).

Bloco de texto com tamanho de fonte abaixo do recomendado (14 pixels)

A frase do propósito do website que está sendo apresentada na homepage é uma informação primária e não pode ter tamanho menor que 16 pixels.

Texto da frase do propósito com tamanho abaixo do recomendado (14 pixels)

Existem outros conteúdo na homepage que também não são considerados como secundários e estão com tamanho abaixo do recomendado, como as informações de reuniões da câmara e as opções do menu

Elementos interativos sobre as reuniões da câmara possuem tamanho de fonte abaixo do recomendado (14 pixels)

Opções do menu com tamanho de fonte abaixo do recomendado

Verificámos que esta situação está a ocorrer em praticamente todas as páginas do website. Apesar de existir uma ferramenta de ampliação disponível, é essencial que todos os blocos de texto e elementos visuais que transmitem informações consideradas como essenciais, por defeito, um tamanho de letra de 16 pixels.

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:

evidência: Existem conteúdos secundários com tamanho de fonte abaixo do recomendado

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

Existem textos secundários com tamanho de fonte abaixo do recomendado. Por exemplo, na página Cartão Barreiro é possível verificar que a data de atualização possui tamanho de 12 pixels. Isso acontece de forma geral no website.

Data de atualização com tamanho de texto abaixo do recomendado (12 pixels)

Por esse motivo recomendamos que todo o seu conteúdo seja revisto para garantir que as informações secundárias tenham tamanho mínimo de 14 pixels.

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

etiqueta: NOK

Lista de evidências recolhidas:

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

etiqueta: chk conteúdoetiqueta: NOKetiqueta: R 2.3

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

Na página Município o número de caracteres no bloco de texto está acima do recomendado (119 caracteres)

Bloco de texto com 119 caracteres na página Município

Isso acontece de forma geral no website e por esse motivo, recomendamos reverem todo o conteúdo para garantir que o número de caracteres dos blocos de texto seja de, no máximo, 100 caracteres.

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: O índice está a ser substituído por acordeões que não estão estruturados corretamente

etiqueta: chk conteúdoetiqueta: NOKetiqueta: R 4.1

Os documentos longos têm um índice no topo com hiperligações internas para o mesmo.
– ver requisito 4.1 na lista Conteúdo

Na página Reuniões, existem acordeões que não estão estruturados corretamente e que devem ser corrigidos:

Estrutura dos acordeões não está acessível quando utilizamos o teclado e leitor de ecrã

Recomendamos rever os acordeões do website para garantir que sejam estruturados corretamente, isso inclui também a página de FAQ na qual indicam na checklist como evidência. Para isso, recomendamos consultarem as notas partilhadas no critério 8.3 da checklist dos 10 aspectos sobre como corrigir o acordeão.
evidência: Não existe um índice no topo de páginas longas

etiqueta: chk conteúdoetiqueta: NOKetiqueta: R 4.1
Os documentos longos têm um índice no topo com hiperligações internas para o mesmo.
– ver requisito 4.1 na lista Conteúdo

Na página Executivo Camarário, é possível verificar que o conteúdo apresentado ultrapassa a altura de três ecrãs. Para contornar esta situação, foi implementado um mecanismo de carregamento adicional no final da página (● ● ●), permitindo ao utilizador aceder a mais informação à medida que faz o scroll para baixo.

No entanto, esta abordagem apresenta problemas:
- Os leitores de ecrã não identificam que existe conteúdo adicional a ser carregado, o que pode comprometer a navegação através de regiões específicas na páginas, como por exemplo, cabeçalhos.
- A dinâmica de carregamento torna difícil obter uma perceção global do conteúdo disponível, uma vez que o seu tamanho varia consoante a quantidade de informação carregada, o que não é imediatamente percetível para o utilizador. Para os leitores de ecrã é mais críticos pois compromete a leitura do conteúdo que ainda não está carregado.
Recomendamos a revisão de todas as páginas do website com o objetivo de substituir o carregamento de conteúdo à medida que se faz scroll por uma navegação com um índice para cada secção interna. Esta abordagem permite que o conteúdo seja apresentado totalmente na página permitindo que os leitores de ecrã identifiquem todo o conteúdo disponível. Para isso, é necessário remover o menu lateral e substituir pelo índice (para mais informações analisarem Outras violações - Existem duas navegações com a mesma informação.

Nota: Esta recomendação aplica-se especificamente a páginas com conteúdo predominantemente textual, como o exemplo apresentado. No caso de páginas extensas compostas por componentes de interação — como a página de Contactos Úteis — não é necessário incluir um índice, uma vez que estas são constituídas por cartões (cards) e elementos interativos. Nestes casos, recomenda-se remover o carregamento progressivo de conteúdo ao fazer scroll e apresentar todo o conteúdo na página.

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:

evidência: Existem elementos interativos com tamanho abaixo do recomendado (44 x 44 pixels)

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

Os controles dos carroseis apresentados na homepage possuem tamanho abaixo do recomendado (15px de largura e 8px de altura). Embora os botões "Voltar" e "Avançar" cumpram esta recomendação, identificámos controlos adicionais — que permitem saltar entre os slides — com dimensões inferiores. Estes também devem respeitar o tamanho mínimo recomendado.

Controles do carrosel da homepage com tamanho abaixo do recomendado (15px de largura e 8px de altura)

Recomendamos que revejam os controlos dos carrosseis do website para garantir que todos tenham, no mínimo, 48 por 48 píxeis.

Possível exemplo de como atribuir aos controles o tamanho mínimo recomendado

Outras violações

etiqueta: NOK

Lista de evidências recolhidas:

evidência: Outras violações - Existem duas navegações com a mesma informação

etiqueta: outras violações

O website da Câmara Municipal do Barreiro apresenta atualmente duas formas de navegação: um menu principal localizado no topo da página e um menu lateral com os mesmos itens de navegação.

No entanto, não se recomenda a apresentação da mesma estrutura de navegação em mais do que um local na página. Esta duplicação pode gerar redundância, excesso de informação e confusão no utilizador, dificultando a identificação do menu principal.

Na imagem abaixo, observa-se a existência simultânea dos dois menus (superior e lateral) e, adicionalmente, o conteúdo da página corresponde novamente a ligações para as mesmas páginas dos menus. Desta forma, são apresentadas três formas diferentes de aceder aos mesmos conteúdos.

Recomendamos reverem a estrutura de navegação e nesse caso, removerem a navegação na lateral (pois também apresenta problemas de interação com o teclado e leitor de ecrã) do website e manter apenas o menu principal no topo. Abaixo partilhamos um possível exemplo:

Exemplo de como a página ficaria sem o menu lateral que está redundante
evidência: Outras violações - Idioma dos elementos interativos dos carrosséis diferente do idioma do site

etiqueta: outras violações

Os textos dos elementos interativos que permitem navegar pelos slides do carrossel existente na secção "Destaques" página inicial não estão em português.

Figura 1 - Carrossel presente na secção destaques, cujos botões de navegação entre slides estão em inglês

Recomendamos a internacionalização dos textos dos componentes interativos de todos os carrosséis, de modo que o seu idioma corresponda ao idioma do sítio web.

Significado das etiquetas utilizadas

etiqueta: OK - status OK
etiqueta: melhoria - status OK, mas pode melhorar
etiqueta: NOK - status Not OK
etiqueta: N/A - status Não Aplicável
etiqueta: chk10 web - checklist 10 Aspetos críticos de acessibilidade funcional
etiqueta: chk conteúdo - checklist Conteúdo
etiqueta: chk transação - checklist Transação
etiqueta: outras violações - permite construir o subcapítulo "Outras violações", o qual integra o capítulo "Avaliações manuais"
etiqueta: dec a11y - permite construir o capítulo "Declaração de acessibilidade e usabilidade"
etiqueta: av auto - permite construir o capítulo "Avaliação automática"
etiqueta: testes usabilidade - permite construir o capítulo "Testes de usabilidade"