O website https://am.cm-camaradelobos.pt/ etiqueta: não passa nos requisitos mínimos do Selo de Usabilidade e Acessibilidade.
| 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.
| Checklist | Conformidade alcançada | Resultado |
|---|---|---|
| 10 aspetos | 36.0% (9/25) | etiqueta: Não passa |
| Conteúdo | 11.8% (2/17) | etiqueta: Não passa |
| Transação | 50.0% (5/10) | 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.
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: issue #2 Avaliação Automática - Access Monitor / Observatório (em avaliação)
Analisámos a amostra com o Access Monitor, de acordo com o método Home+, tendo sido avaliadas, no total, 25 páginas.
Destas páginas, 3 têm pontuação abaixo de 9:
Para mais informação sobre os erros de acessibilidade que existem nessas páginas podem consultar o ficheiro .csv:
06052026_assembleiamunicipallobos.csv
A correção desses erros fará aumentar a pontuação.
Nota: A atualização ainda não foi efetuada no ambiente de produção nem no Observatório, pelo que estes valores ainda não se encontram públicos.
Figura 1 - Indicadores e conformidade do sítio web
evidência: issue #1 Existem erros de acessibilidade
Efetuámos também uma análise com o validador Rocket Validator que indica a existência de 396 erros de Acessibilidade e que precisam ser corrigidos:
Figura 1 - Análise automática feita pelo Rocket Validator indica 396 erros de acessibilidade em uma amostra de 19 páginas
Para mais informações partilhamos o relatório da análise automática feita pelo Rocket Validator.
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.
etiqueta: NOK
Nível de conformidade:
etiqueta: NOK
Lista de evidências recolhidas:
evidência: issue #56 O menu principal não está estruturado como uma lista
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", role="menuitem" e aria-haspopup 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:
Leitor de ecrã apenas diz "Assembleia" e não que é o começo de uma lista
Opção do menu "Assembleia" com o atributo role="menuitem" e aria-haspopup="true"
URL's a verificar:
Recomendações:
Remover os atributos role="menubar", role="menuitem" e aria-haspopup="true" do menu principal.
etiqueta: NOK
Lista de evidências recolhidas:
evidência: issue #78 Subopções do menu não podem ser abertas com o VoiceOver
É possível selecionar as opções e as subopções do menu quer com rato quer com teclado.
Evidencias:
Ao navegar com o leitor de ecrã VoiceOver, não é possível abrir as subopções do menu utilizando o comando VO + Espaço.
Isto acontece porque a abertura e fecho das opções do menu são geridos através do evento keydown, impedindo a interação correta com tecnologias de apoio.
Imagem dos eventos do acordeão do menu secundário.
URL's a verificar:
Recomendações:
evidência: issue #58 Os menus não estão estruturados como uma navegação de forma apropriada
É possível selecionar as opções e as subopções do menu quer com rato quer com teclado.
Evidencias:
Verifica-se que não está a ser utilizado a tag nav em nenhum menu de navegação, excepto os breadcrumbs. Isso faz com que ao navegar pelo website com o leitor de ecrã, não é possível realizar saltos diretamente para o menu, nem este é identificado como uma área de navegação:
Menu principal não identificado como nav
Menu secundário não identificado como nav
URL's a verificar:
Recomendações:
nav.nav corretamente identificada. Para isso podem utilizar o atributo aria-label.evidência: issue #57 Estado do acordeão não é anunciado pelo leitor de ecrã no menu secundário
É possível selecionar as opções e as subopções do menu quer com rato quer com teclado.
Evidencias:
Ao navegar no menu secundário com rato ou teclado, o leitor de ecrã identifica como clicáveis apenas as opções que possuem subopções (acordeão). No entanto, o estado do acordeão (“expandido” ou “colapsado”) não é anunciado.
Isto acontece porque o componente não utiliza o atributo aria-expanded, impedindo que o leitor de ecrã comunique corretamente o estado do acordeão ao utilizador.
Imagem do leitor de ecrã não identificando o acordeão como expandido ou colapsado, mas apenas como "clickable".
Acordeão do menu secundário sem a tag aria-expanded.
URL's a verificar:
Recomendações:
etiqueta: NOK
Lista de evidências recolhidas:
evidência: issue #59 O menu mobile está com texto alternativo inapropriado
As imagem-link, caso existam no menu, devem ter o correspondente equivalente alternativo em texto.
Evidencias:
Quando o menu mobile é aberto, a respectiva imagem do menu se altera para o fechar (X). No entanto, o seu nome acessível não se altera:
Imagem da imagem do menu para fechar com o label "Open mobile menu"
Outro cenário acontece no menu, o leitor de ecrã está a anunciar o menu mobile como "Open mobile menu". Isso acontece porque o seu nome acessível está em inglês:
Imagem do botão de fechar do menu com a aria-label="Open mobile menu"
Recomendações:
etiqueta: NOK
Lista de evidências recolhidas:
evidência: issue #16 Cabeçalho h1 genérico em todas as páginas
Existe um título
<h1>marcado na página.
Evidências
Actualmente, todas as páginas apresentam o mesmo <h1> ("Portal da Assembleia Municipal de Câmara de Lobos"). 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.
Figura 1 - Exemplo do <h1> estar igual em todas as páginas .
URLs a verificar:
Verificar todas as páginas do website.
Recomendações
evidência: issue #15 Existência de multiplos h1 na página web
Existe um título
<h1>marcado na página.
Evidências
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ã.
Figura 1 - Identificação de dois cabeçalhos marcados com <h1> na mesma página. .
URLs a verificar:
Recomendações
etiqueta: NOK
Lista de evidências recolhidas:
evidência: issue #52 Incorreta marcação de títulos e subtítulos
Existe uma marcação hierarquizada de títulos e subtítulos na página
<h1>...<h6>.
– ver requisito 2.2 na lista 10 aspetos
Evidências
Foram identificadas secções do website onde elementos que funcionam visualmente como títulos e subtítulos se encontram marcados com <div> em vez de elementos de cabeçalho semanticamente adequados.
Esta implementação compromete a correta estrutura hierárquica da página e dificulta a navegação por utilizadores de tecnologias de apoio.
Figura 1 - Exemplo de um título de secção marcado com <div> em vez de um elemento de cabeçalho.
Figura 2 - Exemplo de um título de cada partido marcado com <div> em vez de um elemento de cabeçalho.
URLs a verificar:
https://am.cm-camaradelobos.pt/assembleia/composicao/deputados-municipais
Recomendações
<div> utilizados como títulos e subtítulos por elementos de cabeçalho semanticamente adequados (<h1>–<h6>).evidência: issue #50 Saltos na hierarquia de cabeçalhos
Existe uma marcação hierarquizada de títulos e subtítulos na página
<h1>...<h6>.
– ver requisito 2.2 na lista 10 aspetos
Evidências
Na página de pesquisa foram identificados saltos na hierarquia de cabeçalhos, verificando-se a utilização de um elemento <h3> imediatamente após um <h1> , sem existência prévia de um <h2> .
Esta implementação compromete a correta estrutura semântica da página e dificulta a navegação por utilizadores de tecnologias de apoio.
Figura 1 - Estrutura de cabeçalhos da página de pesquisa.
URLs a verificar:
Recomendações
etiqueta: NOK
Lista de evidências recolhidas:
evidência: issue #45 Existem campos de formulário sem etiquetas associadas
Ao clicar com o rato na etiqueta, o cursor surge no respetivo campo de edição.
– ver requisito 4.1 na lista 10 aspetos
Evidências
Nos formulários de filtro das páginas do "Diretório de Documentos", verificámos que os campos “Categoria” e “Subcategoria” têm uma etiqueta corretamente definida no código HTML, associada ao elemento <select> nativo.
No entanto, este elemento <select> encontra-se oculto (aria-hidden="true") e não corresponde ao componente efetivamente utilizado pelo utilizador.
A interação é realizada através de um componente personalizado (Select2), renderizado como um elemento <span role="combobox">, que não está associado programaticamente à respetiva etiqueta <label>.
Figura 1 - Campo "Categoria” sem etiquetas associadas
Como consequência, a relação entre a etiqueta e o controlo interativo visível não é corretamente estabelecida, o que pode afetar a interpretação do campo por tecnologias de apoio e a coerência da interação com o utilizador.
URLs a verificar
Recomendações
Recomenda-se a revisão das comboboxes presentes nos formulários de filtro, adotando uma das seguintes abordagens:
<select>, garantindo mecanismos de acessibilidade já suportados de forma consistente pelos navegadores e tecnologias de apoio;ou
Para tal, pode ser seguido o exemplo da W3C:
Editable Combobox With Both List and Inline Autocomplete (W3C)
etiqueta: NOK
Lista de evidências recolhidas:
evidência: issue #47 Há campos obrigatórios que não estão identificados programaticamente
É 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
Verificámos que, em alguns campos do formulário "Inscrição na Sessão da Assembleia", existem campos de preenchimento obrigatório que não estão programaticamente definidos como tal.
Figura 1 - Análise do campo "Declaro sob compromisso de honra a veracidade do reporte submetido e assumo toda a responsabilidade consequente de falsas declarações ou inexatidão".
Para além disso, existem campos em que o atributo required tem uma sintaxe incorreta (foi utilizado required = "", em vez de required ou required = "true"), para além de que não é necessário utilizar os dois atributos (required e aria-required) ao mesmo tempo.
Acresce ainda que foram inseridos atributos aria-required = "true" em etiquetas. Atributos required ou aria-required em etiquetas não têm qualquer efeito, bem pelo contrário, são semanticamente incorretos e dificultam a manutenção do site.
Figura 2 - Etiqueta com o atributo aria-required
URLs a verificar
Recomendações
required de forma a reforçar aos utilizadores de tecnologias de apoio que o campo em questão é um campo de preenchimento obrigatório.required nos elementos que já o têm, e que, no caso da existência dos atributos required e aria-required, permaneça apenas o atributo required.required e aria-required de todas as etiquetas (<label>).etiqueta: OK (no entanto contém 1 melhoria que se recomenda efetuar)
Lista de evidências recolhidas:
evidência: issue #3 (Melhoria) Imagem decorativa com texto alternativo indevido
A imagem ou gráfico tem um equivalente em texto curto e correto.
– ver requisito 5.1 na lista 10 aspetos
Evidências
Verifica-se que algumas imagens funcionam apenas como apoio visual, encontrando-se a informação relevante já disponibilizada através de título, descrição e links acessíveis em texto. Nestes casos, as imagens podem ser tratadas como decorativas, devendo possuir alt="".
Verificado que alguns nomes alternativos das imagens incluem caracteres especiais (como _), que estão a ser lidos pelo leitor de ecrã como "sublinhado".
Quando a imagem não for decorativa, é recomendado que o equivalente alternativo seja apresentado em linguagem natural, sem identificadores técnicos ou caracteres desnecessários. Nesse caso, são decorativas.
URLs a verificar
Recomendações
etiqueta: OK (no entanto contém 1 melhoria que se recomenda efetuar)
Lista de evidências recolhidas:
evidência: issue #5 (Melhoria) Imagem/gráfico não é acompanhado de uma descrição longa
O gráfico é acompanhado de uma descrição longa.
– ver requisito 5.2 na lista 10 aspetos
Evidências
Verifica‑se que a imagem contém informação relevante sobre a prestação de contas da assembléia. No entanto, o texto alternativo associado não transmite a totalidade da informação presente na imagem, e o link disponibilizado em anexo também não apresenta uma alternativa textual equivalente.
URLs a verificar
Recomendações
etiqueta: NOK
Lista de evidências recolhidas:
evidência: issue #10 Imagens link com texto alternativo incorreto
As imagens-link têm um equivalente alternativo correto.
– ver requisito 5.3 na lista 10 aspetos
Evidências
Verifica-se que a imagem do logótipo utilizada como link para a página inicial, apresenta um texto alternativo que não descreve adequadamente o seu propósito (acesso à página inicial).
Verifica-se que alguns logótipos presentes no rodapé possuem textos alternativos definidos apenas com siglas, como “RAM” e “ALRAM”. Estes textos não refletem de forma clara o conteúdo ou a finalidade dos logótipos para os utilizadores de leitores de ecrã.
Uma vez que as siglas podem não ser compreendidas por todos os utilizadores, o texto alternativo deve apresentar a designação completa da entidade representada pelo logótipo. Por exemplo, em vez de alt="RAM", recomenda-se utilizar alt="Região Autónoma da Madeira".
URLs a verificar
Recomendações
evidência: issue #4 Imagem-link com nome acessível definido incorretamente através de title
As imagens-link têm um equivalente alternativo correto.
– ver requisito 5.3 na lista 10 aspetos
Evidências
Verifica-se que a imagem-link da pesquisa esta 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.
URLs a verificar
https://am.cm-camaradelobos.pt/pesquisar
etiqueta: NOK
Lista de evidências recolhidas:
evidência: issue #80 Texto normal não tem contraste suficiente
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.
Figura 1 - Exemplo de texto normal com problemas de contras na página .
Figura 2 - Exemplo de texto normal com problemas de contras no footer da página Homepage .
Figura 3 - Exemplo de texto normal com problemas de contras no footer da página Sessões de Assembleia .
URLs a verificar:
https://am.cm-camaradelobos.pt/assembleia/assembleia-municipal/sessoes-de-assembleia
https://am.cm-camaradelobos.pt/assembleia/informacoes-uteis/noticias/detalhe/741-compete-a-assembleia-municipal-sob-proposta-da-camara
https://am.cm-camaradelobos.pt/assembleia/informacoes-uteis/noticias/detalhe/743-assembleia-municipal-discute-temas-fundamentais-para-o-futuro-de-camara-de-lobos
Recomendações
etiqueta: N/A
Lista de evidências recolhidas:
evidência: issue #75 Não foram encontrados players no website.
Deve ser possível ativar os botões de controlo do leitor quer com o rato quer com o teclado.
– ver requisito 7.1 na lista 10 aspetos
Evidências
Não foram encontrados players no website, tornando este critério N/A.
Recomendações
etiqueta: N/A
Lista de evidências recolhidas:
evidência: issue #74 Não foram encontrados players no website.
O vídeo ou áudio deve conter preferencialmente legendas fechadas sincronizadas.
– ver requisito 7.2 na lista 10 aspetos
Evidências
Não foram encontrados players no website, tornando este critério N/A.
Recomendações
etiqueta: NOK
Lista de evidências recolhidas:
evidência: issue #32 Botão de submissão associado ao formulário encontra-se fora do elemento
Quando se retira a CSS, a informação aparece numa ordem lógica.
– ver requisito 8.2 na lista 10 aspetos
Evidências
Na página “Inscrição na Sessão da Assembleia”, o botão visível utilizado para iniciar a submissão do formulário (“Enviar”) encontra-se programaticamente fora do elemento <form>.
Embora exista um botão submit dentro do formulário, este encontra-se oculto (display:none), sendo a interação principal dependente de um botão externo acionado via JavaScript.
Esta implementação pode comprometer a relação programática entre o formulário e o respetivo mecanismo de submissão, originando comportamentos inconsistentes para utilizadores de tecnologias de apoio, navegação exclusiva por teclado ou agentes que dependem da semântica HTML nativa.
A ausência de uma associação nativa entre o botão principal e o formulário pode:
Figura 1 - Botão de submissão visualmente associado ao formulário, mas programaticamente fora do elemento <form>
URLs a verificar
Recomendamos que o botão de submissão principal:
<form>; ouform, quando tecnicamente necessário.Adicionalmente, recomenda-se a utilização de um controlo nativo de submissão (type="submit") como mecanismo principal, evitando dependência exclusiva de JavaScript para operações essenciais do formulário.
evidência: issue #14 Formulário de pesquisa avançada exposto ao leitor de ecrã antes de estar visível em mobile
Quando se retira a CSS, a informação aparece numa ordem lógica.
– ver requisito 8.2 na lista 10 aspetos
Evidências
Na versão mobile da página observada, o formulário de “Pesquisa avançada” encontra-se visualmente oculto por defeito, sendo apresentado apenas após ativação do respetivo botão.
No entanto, apesar de não estar visível na interface, o formulário permanece disponível na árvore de acessibilidade e pode ser imediatamente navegado por leitores de ecrã.
Como consequência, a ordem de leitura disponibilizada às tecnologias de apoio não corresponde à sequência visual efetivamente apresentada ao utilizador, originando uma inconsistência entre a interface visível e a informação exposta programaticamente.
Figura 1 - Formulário oculto visualmente mas disponível ao leitor de ecrã antes da ativação da pesquisa avançada
URLs a verificar
Recomendações
hidden;display: none;aria-hidden="true" enquanto o painel estiver fechado.etiqueta: NOK
Lista de evidências recolhidas:
evidência: issue #72 Imagens acionáveis da galeria implementadas apenas como imagens
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
Nas páginas de notícia com galeria de imagens, verificou-se que as miniaturas apresentadas são acionáveis (abrem uma modal/galeria de imagens), mas encontram-se implementadas apenas através de elementos <img> inseridos em elementos genéricos (<div>), sem estrutura semântica apropriada para elementos interativos.
Apesar de permitirem abrir a galeria/modal, estas imagens não estão estruturadas como imagens-link nem como outro elemento interativo semanticamente apropriado.
Como consequência:
Figura 1 - Imagens acionáveis da galeria implementadas apenas como <img>
URLs a verificar
Recomendações
Recomenda-se que as imagens acionáveis da galeria sejam estruturadas através de elementos semanticamente adequados para interação, nomeadamente:
<a><img></a>), quando apropriado;ou
Garantir ainda que:
evidência: issue #61 Campos obrigatórios ocultos permanecem no DOM e podem interferir com a validação do formulário
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 formulário analisado foram identificados vários campos que permanecem presentes no DOM mesmo quando não são apresentados ao utilizador, estando ocultos através de display:none.
Apesar de não estarem visíveis nem serem interagíveis, estes campos mantêm atributos de validação e acessibilidade, como required e aria-required="true", bem como associações de label através do atributo for.
Exemplos identificados no formulário:
Campos de descrição condicionais:
descOpiniaodescSugestoesdescEcosSugestoesCampos de upload de documentos condicionais:
fileuploaddocInscricoesfileuploaddocSugestoesfileuploaddocOpiniaoOutros campos ocultos associados a diferentes fluxos do formulário (ex.: inscrições, sugestões e opinião)
Estes elementos não são apresentados ao utilizador em determinados estados do formulário, mas continuam a existir na estrutura ativa da página.
Figura 1 - Campos de formulário condicionais ocultos no DOM com validação ativa
URLs a verificar
Recomendações
Recomenda-se que os campos que não são utilizados em determinados contextos do formulário sejam tratados de forma adequada, garantindo que não permanecem como elementos ativos e obrigatórios no DOM.
Devem ser consideradas as seguintes abordagens:
Deve ser evitada a utilização de display:none em campos com validação ativa (required), especialmente quando estes fazem parte de fluxos condicionais do formulário.
evidência: issue #31 Controlos de fecho de modal/carousel implementados com elementos não semânticos
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 modal/carousel observado, o controlo de fecho é implementado através de um elemento genérico (<div>), utilizado para executar uma ação de interface.
Apesar de o elemento poder ser focável e interativo através de JavaScript, não utiliza um elemento HTML semântico apropriado para ações, como <button>.
Como consequência, a função do controlo não é corretamente transmitida de forma nativa às tecnologias de apoio, dependendo de atributos adicionais e comportamento programado para simular a sua funcionalidade.
Figura 1 – Controlo de fecho de modal/carousel implementado com <div> em vez de <button>
URLs a verificar
Recomendações
<div> por um elemento semântico <button> para o controlo de fecho.evidência: issue #30 Modais sem nome acessível programaticamente determinável
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 modal observada, embora exista a utilização de role="dialog" e aria-modal="true", não existe qualquer nome acessível associado à janela.
Não é feita associação a um título visível através de aria-labelledby, nem é fornecido um nome alternativo através de aria-label.
Como consequência, quando a modal é aberta, os leitores de ecrã podem anunciar apenas que se trata de um diálogo, sem identificar a sua finalidade ou o contexto apresentado ao utilizador.
Figura 1 – Modal sem nome acessível programaticamente determinável
URLs a verificar
Recomendações
aria-labelledby.aria-label.evidência: issue #29 Controlos do slider utilizam hiperligações em vez de botões e apresentam nomes acessíveis pouco descritivos
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
Foi identificado que os controlos de navegação do slider (“anterior” e “seguinte”) foram implementados utilizando elementos <a href="#">, apesar de representarem uma ação sobre o conteúdo apresentado (alteração do slide) e não uma navegação para outra página.
Embora esta abordagem possa funcionar tecnicamente, a utilização de elementos semânticos mais adequados à ação desempenhada pode melhorar a robustez, previsibilidade e interpretação do componente por tecnologias de apoio.
Adicionalmente, o nome acessível dos controlos depende exclusivamente do atributo alt das imagens internas, ficando a identificação do controlo dependente do conteúdo gráfico e não do próprio elemento interativo.
Figura 1 - Controlos de navegação do slider implementados com elementos <a> e nome acessível dependente do atributo alt da imagem
URLs a verificar
Recomendações
<a href="#"> por elementos <button type="button">, semanticamente mais adequados para ações de interface como a navegação entre slides;aria-label="Slide anterior" e aria-label="Slide seguinte"), evitando dependência exclusiva do atributo alt da imagem;alt="" e aria-hidden="true"), evitando redundância na leitura por tecnologias de apoio;evidência: issue #28 Duplicação de links para o mesmo conteúdo
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:
<a> que envolve a imagem (<img>)<a> que envolve o título (<h3>), funcionando como chamada principal do conteúdoAmbos apontam para a mesma página, resultando em redundância de navegação e aumento do número de elementos interativos.
Figura 1 – Duplicação de links no mesmo bloco de conteúdo
URLs a verificar
Recomendações
evidência: issue #27 Listagem de conteúdos sem estrutura semântica adequada
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.
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.
Adicionalmente, foram identificados casos de utilização de listas de definição (
Por exemplo, a data de atualização de conteúdos é apresentada através de uma estrutura de lista de definição, apesar de não existir uma relação semântica adequada entre termo e definição.
Figura 2 - Informação de atualização estruturada com lista de definição sem relação semântica apropriada
Quando se utilizam elementos semânticos para fins diferentes dos previstos, a estrutura do conteúdo pode ser interpretada incorretamente por tecnologias de apoio, comprometendo a compreensão da informação e a consistência semântica da página.
URLs a verificar
Recomendações
<ul> ou <ol>), com cada item representado por um <li>.<li>.<div>) para representar agrupamentos de conteúdos.<dl>, <dt>, <dd>) apenas quando exista efetivamente uma relação termo-definição;<p>, <div> ou <time>, sem recorrer a listas de definição indevidas;evidência: issue #26 Ausência de landmarks semânticos
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 a ausência de landmarks semânticos que permitam identificar programaticamente as principais regiões da página (ex.: cabeçalho, navegação, conteúdo principal e rodapé). A estrutura da interface aparenta estar predominantemente assente em elementos genéricos (<div>), sem utilização consistente de elementos HTML semânticos ou roles equivalentes.
A inexistência destas regiões semânticas dificulta a navegação por tecnologias de apoio, nomeadamente leitores de ecrã, impedindo os utilizadores de saltar rapidamente entre áreas relevantes da página.
Figura 1 - Ausência de landmarks semânticos identificáveis na estrutura da página
URLs a verificar
Recomendações
<header>, <nav>, <main> e <footer><main>) por páginarole="banner", role="navigation", role="main" e role="contentinfo"Referência: MDN – ARIA landmark roles
etiqueta: NOK
Lista de evidências recolhidas:
evidência: issue #13 Modal não é apresentado integralmente em primeiro plano
Quando se retira o CSS, a informação relevante permanece visível.
– ver requisito 8.4 na lista 10 aspetos
Evidências
No componente de modal/carousel de galeria, verificámos que, após a sua abertura, alguns elementos da interface permanecem visualmente sobrepostos ao modal, nomeadamente a barra de navegação fixa e, em determinadas situações, o rodapé da página.
Como consequência, o conteúdo do modal não é apresentado integralmente em primeiro plano, ficando elementos essenciais parcialmente ocultos, incluindo o controlo de fecho da modal ou os botões de navegação.
Em vários cenários observados, o botão de fechar surge oculto pela navegação superior devido à sobreposição de outros elementos da interface, dificultando ou impossibilitando o encerramento da modal.
Figura 1 - Elementos essenciais da modal ocultos pela barra de navegação e rodapé
URLs a verificar
Recomendações
Recomendamos garantir que o componente modal seja apresentado integralmente acima dos restantes conteúdos da página, assegurando que:
stacking context) aos restantes elementos da interface;Do ponto de vista técnico, recomenda-se rever a implementação de z-index e contextos de empilhamento (stacking context), garantindo que a modal é apresentada acima de todos os elementos decorativos ou estruturais da página.
etiqueta: NOK
Lista de evidências recolhidas:
evidência: issue #6 Quando a caixa de diálogo é aberta, o foco não move-se para dentro da caixa de diálogo
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 não move-se para dentro da caixa de diálogo.
URLs a verificar
Recomendações
etiqueta: NOK
Lista de evidências recolhidas:
evidência: issue #8 Foco não fica limitado a caixa de diálogo
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
Verifica-se que, quando a janela modal está aberta, o foco do teclado e do leitor de ecrã não permanece limitado à modal, permitindo que o utilizador navegue para elementos externos à mesma.
URLs a verificar
Recomendações
etiqueta: NOK
Lista de evidências recolhidas:
evidência: issue #9 A caixa de diálogo não pode ser encerrada através de tecnologias de apoio.
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, ao abrir/expandir uma imagem na galeria, o conteúdo da modal não é ajustada corretamente à área disponível do ecrã. A parte superior do conteúdo fica cortada/sobreposta pelo cabeçalho do site, impedindo a visualização completa da imagem na modal e impedindo acesso ao botão fechar através do rato. O botão fechar está acessível apenas para tecnologias de apoio.
URLs a verificar
Recomendações
etiqueta: NOK
Lista de evidências recolhidas:
evidência: issue #17 Quando a caixa de diálogo fecha, o foco não volta ao elemento interativo que o acionou.
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
Validado que ao fechar a modal o foco não retorna ao elemento que a acionou. Ao navegar com o leitor de ecrã utilizando os comandos VO + espaço (Voice Over), ao fechar a galeria o foco não regressa ao elemento que a acionou. Isso acontece quando efetuamos a abertura da galeria de imagens e navegamos pelo conteúdo antes de fechar.
URLs a verificar
Recomendações
etiqueta: NOK
Nível de conformidade:
etiqueta: NOK
Lista de evidências recolhidas:
evidência: issue #22 Falta de resumo visível na página principal
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 da Assembleia Municipal de Câmara Municipal de Câmara de Lobos, não aparece presente um resumo breve do próposito do site.
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:
Imagem exemplo de uma frase de propósito do website selo.usabilidade.gov
etiqueta: NOK
Lista de evidências recolhidas:
evidência: issue #21 Falta de glossário para termos complexos
Os termos mais complexos têm uma definição agregada.
– ver requisito 1.2 na lista Conteúdo
Evidências:
Ao longo do website, é possível identificar a utilização de diversos termos técnicos e complexos que surgem sem qualquer definição ou explicação associada. Na ausência de um glossário ou de mecanismos que permitam esclarecer esses conceitos, os utilizadores podem ter dificuldade em compreender plenamente a informação apresentada, especialmente aqueles que não estão familiarizados com a terminologia utilizada.
Imagem com o termo complexo "JPP" sem definição agregada. Disponível em: https://am.cm-camaradelobos.pt/assembleia/composicao/deputados-municipais
Imagem com diversos termos complexos no rodapé sem definição agregada. Disponível em: https://am.cm-camaradelobos.pt/assembleia/informacoes-uteis/noticias/detalhe/743-assembleia-municipal-discute-temas-fundamentais-para-o-futuro-de-camara-de-lobos
URL's a verificar:
Recomendações:
Recomenda-se a criação de um glossário que permita a utilização consistente de siglas ao longo do website, evitando que o utilizador tenha de procurar repetidamente a sua definição noutros parágrafos.
Como exemplo podem visualizar o glossario do acessibilidade.gov.
etiqueta: NOK
Lista de evidências recolhidas:
evidência: issue #67 O conteúdo do site fica desformatado em resoluções mais pequenas
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
Evidencias:
Verificou-se que, na página Sessões de Assembleia, um bloco de texto apresenta tamanho de letra reduzido em resoluções mais pequenas, dificultando a leitura e perceção da informação apresentada em dispositivos móveis. (Figura01)
Figura 01 — Bloco de texto com tamanho de letra reduzido em resoluções mais pequenas.
Urls a verificar:
Recomendações:
Recomenda-se assegurar que os blocos de texto do corpo das páginas utilizam tamanhos de letra adequados em diferentes resoluções, garantindo uma leitura confortável e uma perceção clara da informação apresentada, incluindo em dispositivos móveis.
evidência: issue #65 O corpo de texto tem um tamanho inferior a 12pt (equivalente a 16px)
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
Evidencias:
Verificamos que, no rodapé do website Assembleia Municipal Câmara de Lobos, as hiperligações apresentam tamanho de letra inferior ao mínimo recomendado para informação primária.
Foi identificado um tamanho de letra de 14px nos elementos do rodapé, comprometendo a legibilidade e perceção das opções de navegação disponíveis. (Figura 01)
Figura 01 — Hiperligações do rodapé com tamanho de letra inferior ao mínimo recomendado para informação primária.
Verificamos que, no menu principal da página inicial Assembleia Municipal Câmara de Lobos, o conteúdo apresentado no submenu “Assembleia” apresenta tamanho de letra inferior ao mínimo recomendado para conteúdos informativos.
Foi identificado um tamanho de texto de 10px no nome associado à Presidente da Assembleia, comprometendo a legibilidade e perceção da informação apresentada. (Figura 02)
Figura 02 — Conteúdo do submenu “Assembleia” com tamanho de letra inferior ao mínimo recomendado para conteúdos informativos.
Url a verificar:
Recomendações:
Recomenda-se o aumento do tamanho de letra aplicado aos elementos identificados, garantindo uma dimensão mínima equivalente a 12 pontos para conteúdos informativos e elementos de navegação.
etiqueta: NOK
Lista de evidências recolhidas:
evidência: issue #83 Logótipos do rodapé com texto de legibilidade reduzida
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
Evidencias:
No rodapé do website Home - Assembleia Municipal Câmara de Lobos, alguns logótipos apresentam texto com dimensão reduzida, dificultando a leitura e perceção da informação associada. (Figura 01)
Figura 01 — Logótipos do rodapé com texto de dimensão reduzida, dificultando a leitura da informação associada.
O tamanho reduzido das letras compromete a legibilidade dos elementos apresentados, especialmente em resoluções mais pequenas ou em situações de ampliação do conteúdo, não garantindo uma leitura clara da informação disponibilizada.
URL a verificar:
Recomendações:
Aumentar o tamanho do texto associado ao logótipo, assegurando níveis adequados de legibilidade para o tamanho de letra de informações secundárias.
evidência: issue #64 A informação secundária tem um tamanho de letra inferior a 10pt (equivalente a 13px)
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
Evidencias:
Verificou-se que, em diferentes páginas do website, a navegação breadcrumb apresenta tamanho de letra inferior ao mínimo recomendado para informação secundária.
Foi identificado um tamanho de letra de 12px nos elementos do breadcrumb, comprometendo a legibilidade da informação de navegação apresentada. (Figura 01)
Figura 01 — Navegação breadcrumb com tamanho de letra inferior ao mínimo recomendado para informação secundária.
Verificamos que, na página Diretório de Documentos, a informação secundária relativa à data de publicação apresenta tamanho de letra inferior ao mínimo recomendado.
Foi identificado um tamanho de letra de 13px no texto “Publicado a 31-12-2021”, comprometendo a legibilidade da meta-informação apresentada. (Figura 02)
Figura 02 — Informação da data de publicação com tamanho de letra inferior ao mínimo recomendado.
URLs a verificar:
Recomendações:
Recomenda-se assegurar que as informações secundárias, como breadcrumbs, datas de publicação e outros elementos de meta-informação, utilizam tamanhos de letra adequados, garantindo a legibilidade e perceção confortável dos conteúdos apresentados em diferentes dispositivos e resoluções.
etiqueta: NOK
Lista de evidências recolhidas:
evidência: issue #63 Existem blocos de textos com mais de 100 caracteres por linha
Blocos e linhas de texto com largura não superior a 100 caracteres.
– ver requisito 2.3 na lista Conteúdo
Evidências:
Verificamos que, no website, existem blocos de texto com largura superior ao número de caracteres recomendado por linha.
Na página Descrição e competências, foram identificados blocos de texto com largura superior a 100 caracteres por linha. Como exemplo, o excerto “Freguesias, das taxas, dos empréstimos, dos planos directores municipais, da alienação ou oneração de bens municipais, das” apresenta122 caracteres, com medição realizada através da ferramenta WordCounter.
Esta situação compromete o conforto de leitura e a continuidade da perceção do conteúdo apresentado. (Figura 01)
Figura 01 — Blocos de texto com largura superior ao número recomendado de caracteres por linha.
Urls a verificar:
Recomendações:
Recomenda-se a revisão dos blocos de texto do website, de forma a evitar linhas excessivamente longas e garantir uma leitura mais confortável dos conteúdos.
Sugere-se ainda a definição de uma largura máxima para os blocos de texto através de CSS max-width, utilizando unidades relativas ao tamanho da fonte, como em ou rem.
etiqueta: NOK
Lista de evidências recolhidas:
evidência: issue #62 O espaçamento entre linhas está abaixo do recomendado
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:
Verificamos que, na página Diretório de Documentos, alguns blocos de texto apresentam espaçamento entre linhas inferior ao mínimo recomendado para leitura confortável.
Foi identificado um espaçamento entre linhas de 40px para um tamanho de letra de 20px, abaixo da proporção mínima recomendada de 1.5x relativamente ao tamanho da fonte. (Figura 01)
Figura 01 — Blocos de texto com espaçamento entre linhas inferior ao mínimo recomendado relativamente ao tamanho da letra.
Outros blocos de textos:
Verificou-se que, na página Notícias, os títulos das notícias apresentam espaçamento vertical excessivo relativamente ao conteúdo associado.
Foi identificado um tamanho de letra de 20px com uma área vertical de cerca de 72px no bloco do título, originando separação excessiva entre elementos relacionados e prejudicando a leitura contínua do conteúdo. (Figura 02)
Figura 02 — Títulos das notícias com espaçamento vertical excessivo relativamente ao conteúdo associado.
URLs a verificar:
Recomendações:
Recomenda-se assegurar que os blocos de texto utilizam um espaçamento entre linhas mínimo de 1.5x relativamente ao tamanho da letra, promovendo uma leitura mais confortável e uma melhor perceção dos conteúdos apresentados.
etiqueta: NOK
Lista de evidências recolhidas:
evidência: issue #54 Excesso de opções no menu do rodapé
Nenhum nível de navegação tem mais de 9 opções.
– ver requisito 3.1 na lista Conteúdo
Evidências:
Os menus de navegação devem se manter equilibrado, nem com demasiadas opções de topo sem opções secundárias, nem com poucas opções de topo e muitas opções secundarias. Nenhum nível de navegação deve ter mais de 9 opções, mas neste caso existe um nível no rodapé com 10 opções.
Imagem do menu "Serviços Municipais" com 10 opções no menu do rodapé.
URL's a verificar:
Recomendações:
Recomenda-se a reorganização destes menus, de forma a reduzir o número de itens apresentados e a estruturar a informação de modo mais claro, simples e intuitivo, promovendo uma melhor experiência de utilização e conformidade com os princípios de acessibilidade.
Com vista à melhoria da usabilidade e conformidade com os princípios de acessibilidade, recomenda-se:
etiqueta: NOK
Lista de evidências recolhidas:
evidência: issue #66 Subopções do menu “Documentos” direcionam para a mesma página com filtros diferentes
A navegação principal está sempre visível e sempre no mesmo local.
– ver requisito 3.2 na lista Conteúdo
Evidências:
A aba do menu “Documentos” apresenta várias subopções que direcionam todas para a página “Diretório de documentos”. A única diferença entre elas é o filtro “Categoria” aplicado automaticamente.
Isto pode causar confusão na navegação, uma vez que o utilizador acredita estar a aceder a páginas diferentes, mas permanece na mesma página. Além disso, o breadcrumb mantém sempre a mesma localização, dificultando a perceção de contexto e estrutura do website.
Na imagem os breadcrumbs estão apenas na página "Diretório de documentos", porém a navegação foi para "Documentos"->"Editais".
Para além disso, existe opções do filtro que não aparecem no menu mas estão presentes em "Todos os arquivos", como "Participação" e "Instalação e Assunção de Funções".
Imagem da falta de opções do filtro no menu.
URL's a verificar:
Recomendações:
evidência: issue #53 Menu secundário sem identificação consistente de navegação
A navegação principal está sempre visível e sempre no mesmo local.
– ver requisito 3.2 na lista Conteúdo
Evidências:
Nas páginas Participação dos Municípes e Inscrição na Sessão da Assembleia, a página atual não é identificada no menu secundário (Ver figura 02).
Figura 02: Imagem da página Inscrição na Sessão da Assembleia sem foco de página atual no menu secundário.
Figura 03: Imagem exemplo de página com foco da página atual no menu secundário.
URL's a verificar:
Recomendações:
etiqueta: NOK
Lista de evidências recolhidas:
evidência: issue #55 Falta de identificação complementar nas hiperligações
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:
Imagem dos títulos de notícias na página inicial com hiperligações sem indicação visual complementar.
Imagem de hiperligações do menu do rodapé sem indicação visual.
URL's a verificar:
Recomendações:
etiqueta: NOK
Lista de evidências recolhidas:
evidência: issue #39 Páginas extensas sem índice de navegação interna entre secções
Os documentos longos têm um índice no topo com hiperligações internas para o mesmo.
– ver requisito 4.1 na lista Conteúdo
Evidências:
Verificamos que a página Acessibilidade apresenta uma extensão superior a três ecrãs de altura sem disponibilizar um índice interno com hiperligações para navegação entre secções.
Esta situação pode dificultar a navegação e localização rápida dos conteúdos ao longo da página.
(Figura 01)
Figura 01 — Página “Acessibilidade” sem índice interno de navegação entre secções.
URL a verificar:
Recomendações:
Recomenda-se disponibilizar um índice no topo das páginas com maior extensão, incluindo hiperligações internas para as diferentes secções e subtítulos existentes ao longo do conteúdo.
A existência de navegação interna facilita o acesso rápido à informação pretendida e melhora a orientação do utilizador em páginas extensas.
etiqueta: NOK
Lista de evidências recolhidas:
evidência: issue #40 Inconsistências de adaptação responsiva e apresentação de conteúdos em dispositivos móveis
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
Evidências:
Verificou-se que, em diferentes secções do website Home - Assembleia Municipal da camera de lobos, os componentes de navegação contextual não são apresentados em determinadas resoluções móveis.
Foi identificado que o breadcrumb e os menus de navegação lateral e submenus associados às secções “Assembleia”, “Documentos” e “Participação” deixam de estar visíveis em versões mobile, dificultando a orientação, navegação hierárquica e acesso às páginas relacionadas. (Figura 01)
Figura 01 — Breadcrumb e menu de navegação lateral não visíveis em dispositivos móveis.
URLs a verificar:
Recomendações:
Recomenda-se assegurar que os elementos de navegação contextual, como breadcrumbs, menus laterais e submenus, permanecem disponíveis e acessíveis em versões mobile do website.
etiqueta: NOK
Lista de evidências recolhidas:
evidência: issue #33 Elementos interativos dependentes de interação por hover para visualização
Não existem elementos interativos acionados apenas com a passagem do rato.
– ver requisito 5.1 na lista Conteúdo
Evidências:
Na página inicial Home - Assembleia Municipal da camera de lobos foi identificado um elemento interativo no rodapé do conteúdo que apenas se torna visível quando o utilizador passa o rato sobre a área correspondente.
Este comportamento impede o acesso à funcionalidade em dispositivos sem interação por hover, como dispositivos móveis ou navegação por teclado. (Figura 01)
Figura 01 — Elemento interativo apresentado apenas através de hover.
URL a verificar:
Recomendações:
Recomenda-se que os elementos interativos permaneçam visíveis independentemente da utilização de hover, garantindo o acesso às funcionalidades também em dispositivos táteis e navegação por teclado.
etiqueta: NOK
Lista de evidências recolhidas:
evidência: issue #34 Elementos interativos com área clicável inferior à dimensão mínima recomendada
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:
Verificamos que, na página inicial Home - Assembleia Municipal da Câmara de Lobos, o botão de abertura da funcionalidade de pesquisa apresenta uma área interativa inferior à dimensão mínima recomendada para elementos acionáveis.
Foi identificado um tamanho de 42x24px no botão representado pelo ícone de lupa, comprometendo a facilidade de utilização, especialmente em dispositivos táteis. (Figura 01)
Figura 01 — Botão da funcionalidade de pesquisa com dimensão inferior ao recomendado.
Verificamos que, na página A Presidente da Assembleia, os botões de partilha para redes sociais apresentam uma área interativa inferior à dimensão mínima recomendada para elementos acionáveis.
Foram identificados botões com dimensões aproximadas de 30x32px, comprometendo a facilidade de utilização, especialmente em dispositivos táteis. (Figura 02)
Figura 02 — Botões de partilha para redes sociais com dimensão inferior ao recomendado.
Verificamos que, na página Inscrição na Sessão da Assembleia, os campos do tipo checkbox apresentam dimensões inferiores ao mínimo recomendado para elementos interativos.
Foi identificada uma altura aproximada de 20px nos checkboxes do formulário, comprometendo a facilidade de seleção, especialmente em dispositivos táteis. (Figura 03)
Figura 03 — Checkboxes do formulário com dimensão inferior ao recomendado.
Verificou-se que, na página Notícias e destaques, alguns campos interativos da área de pesquisa apresentam dimensões inferiores ao mínimo recomendado para elementos acionáveis.
Foram identificadas alturas de 37.6px no campo “Pesquisa livre” e de 36.1px no campo de seleção “Ano”, comprometendo a facilidade de utilização, especialmente em dispositivos táteis. (Figura 04)
Figura 04 — Campo “Ano” com dimensão inferior ao mínimo recomendado para elementos interativos.
URLs a verificar:
Recomendações:
Recomenda-se assegurar que os elementos interativos apresentam uma área mínima de interação adequada, com no mínimo 44x44px, facilitando a sua utilização em diferentes dispositivos, especialmente em interfaces táteis.
Botões, ícones, controlos de partilha e campos de seleção deverão apresentar dimensões suficientes para permitir uma interação confortável e reduzir seleções incorretas.
etiqueta: NOK
Lista de evidências recolhidas:
evidência: issue #35 Hierarquia visual insuficiente entre ações principais e elementos informativos
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:
Verificamos que na página Atas da assembleia, o botão “Limpar filtro” não apresenta o destaque visual esperado para a ação principal da área de filtros, sendo apresentado visualmente como texto simples, enquanto o botão secundário “Voltar atrás” surge com maior evidência visual.
Os botões secundários deverão apresentar menor destaque visual relativamente às ações principais.
Esta situação dificulta a identificação da ação principal disponível. (Figura 01).
Figura 01 — Botão “Limpar filtro” com reduzido destaque visual relativamente à ação secundária.
URLs a verificar:
Recomendações:
Recomenda-se diferenciar visualmente as ações principais das ações secundárias, garantindo maior destaque aos botões de maior relevância funcional dentro da interface.
Os botões principais deverão apresentar maior evidência visual relativamente às restantes ações disponíveis, facilitando a identificação e compreensão da ação prioritária por parte dos utilizadores.
etiqueta: NOK
Lista de evidências recolhidas:
evidência: issue #37 Elementos interativos sem diferenciação visual clara ou comportamento consistente de interação
Elementos gráficos interativos têm de aparentar ser clicáveis.
– ver requisito 5.4 na lista Conteúdo
Evidências:
Verificou-se que, na página Utentes do programa municipal de atividade física Saúde Rural, existe uma imagem interativa sem indicação visual clara de clicabilidade.
Foi identificado que a imagem pode ser selecionada, mas não aparenta ser clicável, não existindo qualquer alteração visual, destaque ou efeito de interação que o indique ao utilizador. (Figura 01)
Figura 01 — Imagem interativa sem indicação visual de clicabilidade.
Verificou-se que, em diferentes páginas do website, existem elementos gráficos que aparentam ser interativos sem apresentarem qualquer funcionalidade associada.
Foi identificado que os ícones em forma de seta apresentados junto a conteúdos e listas aparentam funcionar como hiperligações ou controlos de navegação, induzindo o utilizador em erro relativamente à sua interatividade.
Como por exemplo página de Contactos. (Figura 01)
Figura 02 — Elementos gráficos com aparência de interatividade sem funcionalidade associada.
Verificamos que o botão “Limpar filtro” da página Atas da assembleia, é apresentado visualmente como texto simples, não apresentando uma aparência consistente com um elemento interativo, tanto em versão desktop como mobile.
Esta situação pode dificultar a identificação da funcionalidade do botão pelos utilizadores.
(Figura 03)
Figura 03 — Controlo “Limpar filtro” sem aparência visual consistente de botão interativo.
Verificou-se que, na página inicial Home - Assembleia Municipal da Câmara de Lobos, o elemento “Contactos” apresenta funcionalidade interativa sem indicação visual adequada.
Foi identificado que o elemento é apresentado visualmente como texto simples, apesar de funcionar como hiperligação, dificultando a perceção da sua interatividade pelos utilizadores. (Figura 04)
Figura 04 — Elemento “Contactos” sem indicação visual adequada de interatividade.
URLs a verificar:
Recomendações:
Recomenda-se diferenciar visualmente os elementos interativos dos restantes conteúdos gráficos e textuais, garantindo que hiperligações, botões e imagens clicáveis aparentam corretamente ser selecionáveis.
Os elementos sem funcionalidade interativa não deverão apresentar aparência de controlo, navegação ou ação clicável, de forma a evitar interpretações incorretas por parte dos utilizadores.
evidência: issue #36 Elementos interativos com contraste insuficiente relativamente ao fundo
Elementos gráficos interativos têm de aparentar ser clicáveis.
– ver requisito 5.4 na lista Conteúdo
Evidências:
Verificou-se que, na página inicial Home - Assembleia Municipal da Câmara de Lobos, os elementos interativos “Assembleia”, “Documentos” e “Participação” apresentam contraste insuficiente no estado hover.
Foi identificado um rácio de contraste de 1.06:1 entre o texto e a cor de fundo durante a interação, abaixo do valor mínimo recomendado para conteúdos interativos. (Figura 01)
Figura 01 — Elementos interativos do menu principal com contraste insuficiente em estado hover.
Verificou-se que, na página Diretório de Documentos, os ícones de seta associados aos campos de seleção apresentam contraste insuficiente relativamente ao fundo do componente.
Foi identificado um rácio de contraste de 2.84:1 entre os ícones de expansão dos campos de seleção e a respetiva cor de fundo, abaixo do valor mínimo recomendado para elementos gráficos interativos. (Figura 02)
Figura 02 — Ícones de expansão dos campos de seleção com contraste insuficiente relativamente ao fundo.
Urls a verificar:
Recomendações:
Recomenda-se assegurar contraste suficiente entre o texto e a cor de fundo nos diferentes estados de interação dos elementos do menu principal, nomeadamente em hover, garantindo a correta perceção e legibilidade dos conteúdos interativos.
etiqueta: NOK
Nível de conformidade:
etiqueta: N/A
Lista de evidências recolhidas:
evidência: issue #43 Não foram encontrados formulários com mais de 2 ecrãs no website
Os formulários com mais de 2 ecrãs de altura devem ser distribuídos por várias páginas.
– ver requisito 1.2 na lista Transação
Evidências
Não foram encontrados formulários com mais de dois ecrãs no site Assembleia Municipal de Câmara de Lobos. Assim, este critério é considerado "Não aplicável (N/A)".
Recomendações
N/A
etiqueta: N/A
Lista de evidências recolhidas:
evidência: issue #46 Não foram encontrados formulários com mais de uma página
Os formulários com mais de uma página têm a sequência de passos ilustrada.
– ver requisito 1.3 na lista Transação
Evidências
Não foram encontrados formulários com mais de uma página dentro do Assembleia Municipal de Câmara de Lobos. Assim, este requisito fica avaliado como "Não Aplicável".
Recomendações
N/A
etiqueta: NOK
Lista de evidências recolhidas:
evidência: issue #85 R 2.1 - Transação- O tamanho dos campos não reflete o tamanho previsível dos dados
Evidências
O tamanho dos campos deve refletir o tamanho previsível dos dados.
– ver requisito 2.1 na lista Transação
Verificámos que na página Inscrição na Sessão da Assembleia alguns dos campos do formulário são demasiado largos para a informação a inserir.
Por exemplo: o número do NIF é constituído por 9 dígitos, no entanto é possível inserir mais de 20 carateres no campo.
Figura 1 - Formulário da página Inscrição na Sessão da Assembleia .
URLs a verificar:
https://am.cm-camaradelobos.pt/participacao/inscricao-na-sessao-da-assembleia
Campos:
Recomendações
etiqueta: NOK
Lista de evidências recolhidas:
evidência: issue #25 Existem campos dependentes de outros campos que estão imediatamente visíveis mas estão inativos
É usada revelação progressiva em vez de campos inativos.
– ver requisito 2.2 na lista Transação
** Evidências**
Verifica-se que o campo “Subcategoria” na pesquisa de documentos, somente fica ativo após o preenchimento do campo Categoria, mas permanece exposto às tecnologias de apoio mesmo quando não existe qualquer categoria selecionada e o respetivo controlo se encontra desativado. Embora visualmente o campo apareça inativo, continua presente na navegação por leitor de ecrã, o que pode levar o utilizador a tentar interagir com um elemento que ainda não está disponível para preenchimento.
URL:
https://am.cm-camaradelobos.pt/documentos/diretorio-de-documentos
No formulário deve-se esconder os campos dependentes do campo-chave sempre que este ainda não tenha sido ativado.
etiqueta: NOK
Lista de evidências recolhidas:
evidência: issue #79 A legenda do campo de pesquisa não é anunciada pelo leitor de ecrã nem aparece na interface
As legendas dos campos são breves e claras.
– ver requisito 2.3 na lista Transação
Evidências:
Verificámos que no campo de pesquisa da página Pesquisar | Motor de busca, existe um elemento <label> dentro da estrutura do formulário, mas este não está a ser reconhecido pelo leitor de ecrã nem está visível na interface gráfica.
Figura - Análise do campo de pesquisa da página Pesquisar | Motor de busca através do Google Inspector.
Recomendações:
Recomendamos que este campo seja reestruturado. Deve ser utilizado um elemento <label> para apresentar a legenda do campo (por exemplo, “Pesquisar:”), que deve ficar acessível para tecnologias de apoio e visível na interface gráfica, e um elemento <input> para o campo onde o utilizador escreve o termo de pesquisa.
Como referência para uma implementação acessível, podem consultar o conteúdo dentro do cabeçalho “Text Inputs”, da página Creating Accessible Forms da WebAIM, onde é apresentado um exemplo claro de como estruturar corretamente este tipo de campo.
evidência: issue #60 Caixas de combinação não estão estruturadas de forma acessível
As legendas dos campos são breves e claras.
– ver requisito 2.3 na lista Transação
Evidências:
Verificámos que, nas comboboxes presentes no website o leitor de ecrã não consegue aceder aos rótulos dos campos — quando o utilizador navega com Tab ou Shift+Tab — nem às opções disponíveis dentro de cada combobox. Quando o utilizador tenta navegar pelas opções, o leitor de ecrã anuncia apenas “blank”, em vez de ler cada opção disponível. Isto significa que estas caixas de combinação não estão estruturadas de forma acessível.
Figura 1 - Análise do campo "Categoria", na página Diretório de documentos, através do leitor de ecrã. Quando o utilizador tenta navegar pelas opções do campo, o leitor de ecrã anuncia apenas “blank”, em vez de ler cada opção disponível.
URL's a verificar:
Recomendações:
Recomendamos que estes componentes sejam reestruturados para garantir total compatibilidade com tecnologias de apoio.
Como referência para uma implementação acessível de uma combobox, recomendamos consultar o exemplo da W3C Editable Combobox With Both List and Inline Autocomplete.
Se concluírem que o número de opções não justifica o uso de uma combobox, podem optar por alternativas mais simples, como listas suspensas ou radio buttons. A página Creating Accessible Forms apresenta exemplos práticos de implementações acessíveis destes componentes.
etiqueta: N/A
Lista de evidências recolhidas:
evidência: issue #41 O critério relativo a formulários PDF não se aplica
Campos obrigatórios devem ser claramente indicados como tal.
– ver requisito 2.4 na lista Transação
Evidências:
O critério não se aplica.
Verificou-se que o website não disponibiliza formulários em formato PDF.
etiqueta: N/A
Lista de evidências recolhidas:
evidência: issue #7 Inexistência de ações longas
Em ações longas, o sistema deve indicar o que está a acontecer.
– ver requisito 3.1 na lista Transação
Evidências
Na análise realizada, não foram identificadas ações longas que exijam comunicação de estado ao utilizador.
Desta forma, considera-se que o critério é não aplicável.
Recomendações
N/A
etiqueta: NOK
Lista de evidências recolhidas:
evidência: issue #18 Feedback após submissão não acessível
Deve ser confirmado o sucesso da transação/envio de informação.
– ver requisito 3.2 na lista Transação
Evidências
Após submissão do formulário:
aria-live, role="alert" ou role="status"Este comportamento compromete a compreensão do estado da interface.
Figura 1 – Mensagem de feedback não anunciada nem acessível por teclado
URL a verificar
Recomendações
aria-live="polite" ou role="status" para mensagens dinâmicasetiqueta: NOK
Lista de evidências recolhidas:
evidência: issue #51 Existem mensagens de erro que não ajudam na resolução do problema
As mensagens de erro devem mostrar os passos concretos para a resolução dos mesmos.
– ver requisito 4.4 na lista Transação
Evidências
A mensagem de erro “O email indicado está inválido.” presente nos formulários da páginas "Reportar Desaparecido" e "Campanhas de Vacinação" não ajuda no preenchimento do campo:
Figura 1 - Mensagem de erro que não guia o utilizador na resolução do erro
Como observado na figura, a mensagem “Por favor, introduza um endereço eletrónico válido.” que é apresentada quando o campo foi preenchido com um formato incorreto não indica qual o formato a ser inserido, não ajudando a preencher o campo.
URLs a verificar
Recomendações
Recomendamos rever todos os formulários do website para garantir que as mensagens de erro apresentadas expliquem para o utilizador como preencher os campos corretamente.
etiqueta: OK (no entanto contém 6 melhorias que se recomenda efetuar)
Lista de evidências recolhidas:
evidência: issue #84 Outras violações - Falha no carregamento dos formulários do website
Verifica‑se que os formulários apresentados no website deixaram de funcionar. Está a ser exibida uma imagem indicando que o conteúdo está a carregar, porém nada é apresentado.
Para além disso, constatamos que essa imagem não possui texto alternativo adequado e, com um leitor de ecrã, não é possível identificar que existe um processo de carregamento em curso. Assim, os utilizadores que dependem de tecnologias de apoio não recebem qualquer indicação de que o formulário está a tentar ser carregado:
URLs a verificar
Recomendações
evidência: issue #81 Outras violações - Foco não está visível na navegação por teclado e leitor de ecrã
Evidências
Ao navegar pelo website utilizando o teclado (TAB) 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.
Figura 1 – Exemplo de ausência de foco visível na navegação por teclado
Figura 2 – Exemplo de ausência de foco visível na navegação utilizando leitor de ecrã
Durante a navegação sequencial através da tecla TAB, há algumas componentes que não são circunscritas pelo foco por exemplo durante a navegação por teclado nos cards das “Notícias” e "Consultas públicas".
Figura 3 - Exemplo de foco escondido por trás dos cards
URLs a verificar
https://am.cm-camaradelobos.pt/
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.
Esta melhoria é essencial para assegurar uma navegação acessível a utilizadores com deficiência visual, motora ou cognitiva
evidência: issue #77 Outras violações - Botão com texto alternativo em inglês
Evidências
Verificado que em todo o website está disponível o botão de seletor de idiomas. No entanto, o elemento apresenta texto alternativo incorreto, definido com aria-label="Select Language". Essa rotulagem em inglês dificulta a compreensão por utilizadores falantes de português, idioma principal em que o site é disponibilizado, especialmente para pessoas que utilizam leitores de ecrã.
URLs a verificar
https://am.cm-camaradelobos.pt/
Recomendações
Recomendamos traduzir todos os textos alternativos dos botões para português, idioma principal do website.
evidência: issue #76 Outras violações - Links e botões que direcionam para PDFs sem aviso prévio
Evidências
O website possui botões e links que direcionam diretamente para ficheiros PDF, sem informar previamente o utilizador sobre esse comportamento. Essa prática pode causar perda de referência de navegação, uma vez que o utilizador é retirado do fluxo do website e, para retornar à página anterior, depende exclusivamente dos controlos do navegador. Por exemplo, ao aceder os conteúdos "Consultar o Regimento", na página Regimento da Assembleia .
URLs a verificar
https://am.cm-camaradelobos.pt/assembleia/assembleia-municipal/regimento-da-assembleia
Recomendações
Ajustar as nomenclaturas dos links e botões para informar claramente que o acionamento irá abrir ou descarregar um ficheiro PDF, por exemplo: “Consultar o Regimento (PDF)”.
Adicionalmente, recomenda-se manter o comportamento consistente em todo o site e, sempre que possível, fornecer avisos acessíveis, promovendo maior previsibilidade, orientação e conformidade com boas práticas de acessibilidade.
evidência: issue #71 Outras violações - Existem opções de menu que não carregam o conteúdo correspondente
Evidências
Verifica-se que, ao selecionar a opção “Presidente da Assembleia” no menu lateral, o conteúdo correspondente não é carregado na área principal da página. O item de menu aparenta ser clicável, no entanto, após a sua seleção não é realizada qualquer ação e a página mantém o conteúdo anteriormente selecionado.
URLs a verificar
https://am.cm-camaradelobos.pt/participacao/participacao-dos-municipes
Recomendações
evidência: issue #68 Outras violações - Existem páginas que apresentam quebra de layout
Evidências
Verifica-se uma quebra no alinhamento do layout da listagem de documentos. Os cartões apresentam alturas e distribuição de conteúdo inconsistentes, fazendo com que a informação “Publicado a...” fique desalinhada entre os diferentes resultados, prejudicando a leitura e a consistência visual da página.
Também foi verificada uma quebra de layout no campo “Pesquisa Livre” ao utilizar o navegador Safari. A label do campo aparece dividida em duas linhas e sobreposta à área do input.
Verifica-se uma quebra de layout na área final do formulário, junto às caixas de seleção obrigatórias e ao botão “Enviar”. O formulário não está corretamente ajustado à área visível da página, fazendo com que parte do conteúdo fique demasiado próxima do rodapé e que o botão de envio apareça deslocado para fora do bloco principal do formulário.
URLs a verificar
Recomendações
Definir limites de extensão para os títulos, usar subtítulos ou texto introdutório para informações complementares e aplicar hierarquia semântica clara (título principal mais curto). Garantir também um layout responsivo que controle a quebra de texto, melhorando a legibilidade e a acessibilidade geral da página.