Relatório Avaliação de Candidatura
Câmara Municipal de Oliveira do Bairro (sítio Web institucional)

Introdução

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

Estado das avaliações efetuadas
Tipo de avaliaçãoEstado
Avaliação Automáticaetiqueta: NOK
Avaliação Manualetiqueta: NOK

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

Níveis de conformidade das avaliações manuais
ChecklistConformidade alcançadaResultado
10 aspetos43.5% (10/23)etiqueta: Não passa
Conteúdo58.8% (10/17)etiqueta: Não passa
Transação45.5% (5/11)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.

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

Declaração de Acessibilidade

etiqueta: NOK

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

Lista de evidências recolhidas:

Avaliação automática

etiqueta: NOK

Para a produção das evidências do presente capítulo, foram utilizadas ferramentas automatizadas de avaliação de requisitos de acessibilidade de acordo com a norma WCAG 2.1 'AA'. A amostra em análise pelas ferramentas é composta pela Homepage mais todas as páginas diretamente hiperligadas por ela, pertencentes ao domínio.

Lista de evidências recolhidas:

Avaliação manual

etiqueta: NOK

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

Sempre que os auditores localizam uma falha grave de um requisito de acessibilidade que, embora não faça parte do esquema de requisitos do Selo, se enquadre no âmbito das violações das WCAG 2.1 'AA' do W3C, tal referência é anotada em "Outras violações" do presente capítulo. Apesar destas violações não se apresentarem com carácter vinculativo no esquema de requisitos do Selo, recomenda-se que as mesmas sejam corrigidas.

Checklist 10 aspetos

etiqueta: NOK

Nível de conformidade:

  • Checklist 10 aspetos: 43.5% (10/23)
    • Requisitos avaliados: 27 (4 N/A excluídos, 23 aplicáveis)
    • Requisitos OK: 10
    • Requisitos NOK: 13
    • Requisitos N/A: 4

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #1 Rodapé possui opções que não estão estruturados como lista

    etiqueta: R 1.1etiqueta: chk 10 webetiqueta: NOK

    Evidências
    Verifica‑se que as opções “CONTACTOS ÚTEIS”, “LINKS ÚTEIS”, “Reclamações e Sugestões”, bem como “Deixe a sua mensagem”, “234 732 100” e “Subscreva a newsletter”, não estão estruturadas como uma lista, apesar de funcionarem como um conjunto de links relacionados:


    URLs a verificar

    Recomendações

    • Embora sejam links distintos, não é possível diferenciar “Reclamações” de “Sugestão e reclamação” apenas pelo nome, pois ambos tem a opção de efetuar uma reclamação. Para evitar ambiguidade e garantir previsibilidade para todos os utilizadores, recomenda‑se que o link “Reclamações” seja renomeado para “Livro de reclamações”.
    • Estruturar os links “CONTACTOS ÚTEIS”, “LINKS ÚTEIS”, “Reclamações e Sugestões” como uma lista ul li.
    • Estruturar os links “Deixe a sua mensagem”, “234 732 100” e “Subscreva a newsletter” como uma lista ul li.

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #92 Não é possível identificar se uma opção possui subopções, nem se estas se encontram expandidas ou recolhidas

    etiqueta: chk 10 webetiqueta: R 1.2etiqueta: NOK

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

    Evidências
    Quando navegamos com o leitor de ecrã Voice Over no Safari, não é possível identificar quais opções do menu possuem subopções. Isto acontece porque o leitor de ecrã não anuncia o estado aberto ou fechado dessas opções, o que dificulta a compreensão da estrutura do menu.

    Atualmente, as opções com subopções são indicadas apenas pela sinalética visual +, mas essa informação não está a ser transmitida corretamente às tecnologias de apoio:

    Leitor de ecrã não anuncia quando a opção está aberta (expandida) ou fechada (compactada)

    Embora o estado aberto/fechado de cada opção seja corretamente anunciado pelo leitor de ecrã NVDA, o mesmo não acontece de forma consistente em outros leitores de ecrã, apesar de utilizarem o atributo aria-expanded.

    A combinação VoiceOver e Safari são mais sensíveis à semântica e a forma de construção dos componentes, o que pode estar a interferir com a correta identificação do estado (aberto/fechado) das opções do menu lateral.

    O que pode estar a acontecer:

    • O atributo aria-expanded está a ser atualizado corretamente, mas não está a ser utilizado em conjunto com aria-controls.
    • Embora os atributos aria-controls e aria-expanded sejam apresentados quando uma opção é expandida, o facto de as subopções e os respetivos atributos serem injetados dinamicamente após a interação pode comprometer a identificação correta do estado pelos leitores de ecrã, em especial o Voice Over.

    URLs a verificar

    Recomendações

    • Apresentar toda a estrutura do menu lateral diretamente no DOM, a visibilidade das opções deve ser controlada via script em conjunto com CSS.
    • Com toda a estrutura do menu disponível desde o início, o atributo aria-controls deve ser definido logo à partida.
    • As opções que contêm subopções devem ser estruturadas em dois elementos distintos: um link, responsável pela navegação para a página correspondente, e um botão +, responsável por expandir e recolher as subopções. Assim corrigi-se também o problema do foco com o leitor de ecrã, pois quando abrimos uma opção o foco é direcionado para o topo da página devido ao carregamento de uma nova url.
    • O botão + deve ter um texto alternativo apropriado.

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

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

Lista de evidências recolhidas:

  • issue #97 As imagens do menu de navegação estão definidas como decorativas

    etiqueta: chk 10 webetiqueta: R 1.3etiqueta: melhoria

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

    Evidências
    O menu lateral do website da CM Oliveira do Bairro apresenta imagens definidas como decorativas, sendo exibidas via CSS

    Ícone (+) sendo apresentado via CSS

    Contudo, recomendamos analisarem a issue #92 pois contém sugestões de correção que são relacionados com este requisito.

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:

  • issue #105 Existem títulos e subtítulos incorretos e outros em falta

    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

    Evidencias:

    Nota: as páginas aqui indicadas são exemplos, devem ser corrigidas todas as situações iguais noutras páginas do site.

    M. Bragança (NOK)

    Evidência checklist: na homepage, a seguir ao título de nível 1, surgem 4 títulos de nível 4 (Contactos/Geoportal/Nopaper/perguntas frequentes), que deveriam passar a ser apenas itens de lista e não cabeçalhos. Esta situação também aparece nas restantes páginas, uma vez que esta seção é comum a todo o site, mas aqui estes títulos de nível 4 aparecem primeiro do que o título nível 1.

    M. Guimarães (NOK)

    • Evidência checklist: na Homepage, hierarquia dos títulos está correta, mas existem demasiados títulos de nível 2 quando poderiam ser apenas lista com itens (caso de "todos os sites do município).
    • Nas pags interiores só existem 4 cabeçalhos (H1 nome da página, e depois sempre os 3 do rodapé), por exemplo em https://www.cm-guimaraes.pt/areas-de-intervencao/ambiente-e-sustentabilidade/mobilidade-e-transportes/modos-suaves deverão existir 4 cabeçalhos de nível 2 abaixo do H1, referentes a MUPI - Cidade ciclável / Metrominuto Guimarães / Metrominuto Caldas das Taipas / Modos suaves em Guimarães. Situação idêntica em: https://www.cm-guimaraes.pt/areas-de-intervencao/protecao-e-seguranca/galeria .

    M. Esposende (NOK)

    • Evidência checklist: na homepage a hierarquia dos títulos está correta, embora existam demasiados títulos de nível 2.
    • Nas páginas interiores passa de título de nível 1 para nível 4, e.g. https://www.municipio.esposende.pt/viver/equipamentos; https://www.municipio.esposende.pt/pages/173, nok

    M. Arcos de Valdevez (NOK)

    • Evidência checklistt: homepage, ok
    • Em https://www.cmav.pt/p/investir, https://www.cmav.pt/informar/orgaos-autarquicos/camara-municipal, e https://www.cmav.pt/contactos, passam de títulos de nível 1 para nível 4 e 5, nok

    M. Águeda (NOK)

    • Evidência checklist, ok
    • Em https://www.cm-agueda.pt/viver/acao-social/agueda-solidaria NOK, situação já referenciada no relatório em jan 2025. Na página Águeda solidária e em muitas outras páginas do site, existe um cabeçalho de nível 1 marcado corretamente, mas não há títulos atribuídos à secção do corpo do documento, porque o primeiro h2 faz parte do conteúdo do rodapé.

    M. Matosinhos (NOK)

    • Evidência checklist: na homepage, existem vários cabeçalhos de nível 2 (carrocel) que surgem antes do cabeçalho nível 1, nok
    • Em https://www.cm-matosinhos.pt/municipio/executivo-municipal/competencias-do-executivo-municipal/marta-moura-laranja-pontes, hierarquia correta mas salta do cabeçalho do nome da página para cabeçalhos de rodapé, não existem títulos atribuídos à secção do corpo da página, nok

    CI Região de Aveiro (NOK)

    • Evidência checklist: homepage, ok
    • Em https://www.regiaodeaveiro.pt/institucional/quem-somos , hierarquia correta mas salta do cabeçalho do nome da página para cabeçalhos de rodapé, não existem títulos atribuídos à secção do corpo da página.

    M. Valpaços (NOK)

    • Evidência checklist: homepage, passa de cabeçalho nível 2 para nível 4, nok
    • Em https://valpacos.pt/municipio/assembleia-municipal , a hierarquia de títulos é violada, passa de nível 1, para nível 4 e depois para nível 6

    M. Sabrosa (NOK)

    • Evidência checklist: homepage, ok
    • Em https://www.sabrosa.pt/autarquia/orgaos-autarquicos/assembleia-municipal , hierarquia correta mas salta do cabeçalho do nome da página para cabeçalhos de rodapé, não existem títulos devidamente marcados no corpo da página, nok

    M. Albergaria-a-Velha (NOK)

    • Evidência checklist: homepage, ok
    • Em https://www.cm-albergaria.pt/municipio/assembleia-municipal/composicao-8 , hierarquia correta mas salta do cabeçalho do nome da página para Contactos, não existem títulos atribuídos à secção do corpo da página, nok

    M. Caminha (NOK)

    • Evidência checklist: homepage, ok
    • Em https://www.cm-caminha.pt/viver/acesso-informacao-administrativa, hierarquia correta mas salta do cabeçalho do nome da página para cabeçalhos de rodapé, não existem títulos atribuídos à secção do corpo da página, nok

    M. Peniche (OK)

    • Evidência checklist: homepage, ok

    M. Peso da Régua (NOK)

    • Evidência checklist: homepage, ok
    • Em https://www.cm-pesoregua.pt/municipio/autarquia/executivo-municipal ou https://www.cm-pesoregua.pt/municipio/autarquia/assembleia-municipal, hierarquia correta mas salta do cabeçalho do nome da página para cabeçalhos de rodapé, não existem títulos atribuídos à secção do corpo da página, nok

    M. Pombal (NOK)

    • Evidência checklist: homepage, não existe título de nível 1 (desconhecemos em que site estamos), nok
    • Em https://www.cm-pombal.pt/municipio/camara-municipal , o título de nível 1 encontra-se no rodapé, nok
    • As páginas deste site, começam com títulos nível 2

    M. Montalegre (OK)

    • Evidência checklist: homepage, ok

    M. Sátão (NOK)

    • Evidência checklist: homepage, existe um carrossel com título nível 2, antes do título de nível 1, nok
      • .
    • Em https://www.cm-satao.pt/autarquia/camara-municipal , além do carrocel com título nível 2, a página não tem título nível 1, com nome da página. Título nível 1, está no rodapé. Para além disso não existem títulos atribuídos à secção do corpo da página, nok

    M. Ílhavo (NOK)

    • Evidência checklist: homepage, ok
    • Em https://www.cm-ilhavo.pt/municipio/assembleia-municipal/composicao-e-competencias salta do cabeçalho do nome da página para cabeçalho de rodapé com o nome do município??, não existem títulos atribuídos à secção do corpo da página, nok.

    M. Oliveira do Bairro (NOK)

    • Evidência checklist: homepage, o primeiro título é de nível 2 e é uma imagem??, nok
    • Em https://www.cm-olb.pt/municipio/camara-municipal/competencias , salta do cabeçalho do nome da página para cabeçalhos de rodapé de nível 2 (Ir para a página inicial??), não existem títulos atribuídos à secção do corpo da página, nok

    CM Vagos (NOK)

    • Evidência checklist: homepage, ok
    • Em muitas das páginas interiores apenas existe o título nível 1, não existem títulos atribuídos à secção no corpo da página e.g. https://www.cm-vagos.pt/municipio/assembleia-municipal/composicao , nok

    M. Valongo (NOK)

    • Evidência checklist: em https://www.cm-valongo.pt/municipio/autarquia/mensagem-do-presidente , página erro 404?!, nok
    • Homepage, hierarquia correta embora com demasiados títulos (150?)
    • Em https://www.cm-valongo.pt/municipio/autarquia , hierarquia correta mas salta do cabeçalho do nome da página para cabeçalhos de rodapé, não existem títulos atribuídos à secção do corpo da página

    Recomendações:

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:

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:

Requisito 5.1 - A imagem ou gráfico tem um equivalente alternativo em texto curto e correto

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #66 Há imagens com textos alternativos incorretos

    etiqueta: chk 10 webetiqueta: NOKetiqueta: R 5.1

    A imagem ou gráfico tem um equivalente em texto curto e correto.
    – ver requisito 5.1 na lista 10 aspetos

    Evidências

    Há imagens informativas que não possuem um texto alternativo. A evidência (1) demonstra que a imagem em destaque na página apresenta um texto alternativo incompleto face ao conteúdo visual. O alt="cegonha" não descreve adequadamente o elemento representado nem contextualiza o propósito da imagem na página, que tem um papel distintivo na identidade visual do município.

    Image

    A evidência (2) revela na notícia “Fernando Pereira nas Conversas da Rádio | 23 de janeiro” a imagem principal da página não possui um texto alternativo que indique que ali existe uma fotografia do cantor Fernando Pereira.

    URLs a verificar

     Recomendações

    Recomenda-se a atualização dos textos alternativos das imagens, de modo a torná-lo mais descritivo e alinhado com a função comunicativa da imagem e refletir fielmente o seu propósito no contexto em que se encontra.

    • Evidência 01- Proposta de texto alternativo: “Fotografia da escultura metálica de uma cegonha com asas abertas, em Oliveira do Bairro.”
    • Evidência 02- Proposta de texto alternativo: "Fotografia do cantor Fernando Pereira, segurando um microfone, em palco iluminado com luzes de espetáculo ao fundo.”
    • Caso seja necessário incluir uma descrição longa da imagem, esta deve ser colocada próxima da imagem ou numa página à parte que esteja hiperligada à imagem em questão.

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #52 Representações gráficas sem descrição longa

    etiqueta: chk 10 webetiqueta: NOKetiqueta: R 5.2

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

    Evidências

    • Gráficos resultantes de análise de dados deverão ser acompanhados da tabela de dados que lhe deu origem, de forma a preservar o acesso à informação completa.

    A evidência (1) revela uma imagem do “Corso carnavalesco” que inclui o percurso do desfile, apresentado em formato de mapa com uma descrição longa incompleta. Embora exista uma legenda para indicar as ruas do percurso, outros elementos importantes como as "Seis zonas de estacionamento" não refletem na descrição textual. Esta omissão impede utilizadores de leitores de ecrã acedam toda a informação disponível no mapa. (Figura 1)

    Image

    Figura 1 - Imagem do mapa do “Corso carnavalesco” sem descrição longa associada

    URLs a verificar

    Recomendações:
    Recomendamos completar a descrição longa para incluir todos os pontos de interesse apresentados no mapa.

    • Adicionar um texto alternativo significativo e disponibilizar uma descrição longa que apresente os elementos estruturais do mapa, garantindo assim uma perceção equitativa da informação.

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #51 Imagens-link com textos alternativos incorretos

    etiqueta: chk 10 webetiqueta: NOKetiqueta: R 5.3

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

    Evidências

    • É necessário rever as boas práticas de acessibilidade em todas as páginas dos websites, uma vez que as evidências apresentadas refletem problemas recorrentes e críticos, como textos alternativos incorretos, uso inadequado de atributos e padrões inconsistentes. A correção deve ser aplicada de forma transversal, garantindo que a acessibilidade seja tratada como padrão e não apenas nos apontamentos aqui colocados.

    As hiperligações compostas apenas por uma imagem obrigam que esta tenha um equivalente alternativo em texto que represente fielmente o destino da hiperligação. A evidência (1) mostra que a imagem “Município Oliveira do Bairro” utiliza um texto alternativo inadequado (alt="Ir para a página inicial"), embora o utilizador já se encontre na página inicial. Além de não refletir o conteúdo da imagem (o logótipo), o texto alternativo apresenta uma função incorreta, o que compromete a perceção do elemento por utilizadores de leitores de ecrã.

    Foram igualmente identificados outros exemplos de textos alternativos incorretos em imagens‑link, como “Deixe a sua mensagem” (alt="mensagem-white"), “234 732 100” (alt="telefone-white"), “Subscreva a newsletter” (alt="icon_plane_rounded2") assim como o grupo de imagens com alt="logotipos acessibilidade”. Estes textos não descrevem o conteúdo nem o propósito das hiperligações, prejudicando a navegação assistiva e violando o presente critério. (Figura 1)

    Image

    Figura 1 - Problemas com imagens link do rodapé

    Verificámos que no rodapé, os logótipos “Cofinanciados por” encontram-se agrupados como uma única imagem com um único link. No entanto, o texto alternativo alt="Centro 2020" direciona apenas para um link que não está funcional. (Figura 2 e 3)

    Image

    Figura 2 - Projetos “Cofinanciados por” com problemas de atribuição incorreta de texto alternativo

    Image

    Figura 3 - Link associado não está funcional com redirecionamento para página com erro

    URLs a verificar

    Recomendação
    Recomendamos a revisão das imagens-link e atualização dos seus textos alternativos, assegurando que descrevem de forma clara e objetiva o conteúdo e o destino da hiperligação.
    Substituir os ícones aplicados via CSS, por SVG inline dentro do HTML, permitindo controlo total sobre acessibilidade. Como os ícones representam ação para o redirecionamento a outras páginas, recomendamos incluir os textos alternativos:

    • <a href="..." aria-label="Livro de Reclamações, abre em link externo”></a>

    Nos casos dos grupos de imagens, a recomendação é remover a atribuição da tag <a href="..."> do grupo de imagens, eliminando a função de imagem como link. Desta forma, o conjunto deve ser tratado como uma única imagem, com um texto alternativo que descreve adequadamente o grupo de imagens. Por exemplo, nos logótipos “Cofinanciados por”: alt="Logótipos Centro 2020, Portugal 2020, União Europeia- Fundos Europeus Estruturais e de Investimento". O mesmo acontece com o grupo de imagens que direciona para a página da declaração de Acessibilidade, pelo que é necessário aplicar a mesma correção.

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

etiqueta: NOK

Lista de evidências recolhidas:

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #91 O botão do menu compacto (mobile e tablet) está visível para leitores de ecrã em desktop

    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

    Evidências
    Com o leitor de ecrã VoiceOver, é possível identificar o botão do menu compacto na versão desktop, utilizando o navegador Safari. Por exemplo, no website da Câmara Municipal de Guimarães, o menu é identificado como uma opção dentro da navegação mesmo estando ocultado via CSS:

    Recomendação

    • Deve ser utilizado o atributo aria-hidden tanto no menu desktop como no menu compacto. O menu que estiver visível no momento deverá ter aria-hidden="false", enquanto o outro deverá manter aria-hidden="true".

  • issue #89 Existem elementos que estão a ser lidos apenas pelos leitores de ecrã

    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

    Evidência
    Verifica-se, nos websites alvo de análise, a existência de elementos que se encontram indevidamente visíveis às tecnologias de apoio, o que gera ruídos e dificulta a interação por parte dos utilizadores.

    Por exemplo, nas páginas internas é apresentada um campo de pesquisa "interno" na qual se verifica a existência de um input do tipo type="image". Esta construção é válida, uma vez que este tipo de input é semelhante a um botão do tipo submit. No entanto, existe uma label associada a este input, o que é incorreto, sendo essa label visível apenas para leitores de ecrã gerando ruídos na navegação:

    Image

    Campo de pesquisa estruturado como botão do tipo input type="image" e com uma label visível aos leitores de ecrã que possui o mesmo nome do botão "Pesquisar"

    URLs a verificar

    Recomendação
    Verificar todos os locais onde o campo de pesquisa é apresentado, garantindo que não é utilizada uma label associada a botões do tipo type="image".

  • issue #57 Ordem dos controles do carrossel não é apropriada

    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

    Descrição do problema:

    Os botões presentes no carrossel da página inicial de Vagos não se encontram estruturalmente adjacentes.

    Image

    Tal obriga a que os utilizadores de leitores de ecrã tenham de percorrer vários itens do carrossel para para procederem à navegação entre o botão “Subir” e o botão “Descer”, o que impacta negativamente a experiência de navegação. Com efeito, a probabilidade de o botão “Descer” não ser encontrado, ou de não ser feita a relação entre os dois botões, é muito elevada.

    Websites que necessitam de correções (NOK):

    Apenas o referido acima.

    Websites que estão a cumprir (OK):

    Não foi identificado o mesmo problema nos seguintes websites:

    Sugestão de correção

    Recomendamos que todos os carrosséis tenham os seus botões estruturalmente adjacentes, fazendo correspondência entre a ordem do html e a ordem visual, de forma a formarem uma estrutura semântica una e assim facilitarem a compreensão e navegação nos vários elementos dos carrosséis.

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #86 O chatbot não está estruturado de forma apropriada

    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](https://amagovpt.github.io/kit-selo/checklists/checklist-10aspetos#n83

    Evidências

    O chatbot está construídos de forma inadequada, uma vez que está sendo utilizado estruturadas como div em vez de elementos nativos do HTML. Isso faz com que seja acessível apenas com o rato.

    Chatbot construído com divs e está inacessível com o teclado e leitor de ecrã

    Recomendações

    • Devem garantir que o chatbot seja acessível através do rato, do teclado e de tecnologias de apoio. Para isso, recomendamos que, sempre que possível, sejam utilizados elementos nativos de HTML, como botões ou links.

  • issue #85 Existem acordeões construídos 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

    Descrição do problema

    Verifica-se que os acordeões apresentados no website estão a ser construídos de forma inadequada, uma vez que são utilizadas divs em vez de utilizar elementos nativos do HTML:

    Acordeão estruturado como div no HTML

    Isto impede que o leitor de ecrã reconheça o elemento como interativo, uma vez que não é indicado que se trata de um botão ou de um link, nem se o elemento se encontra aberto ou fechado:

    Leitor de ecrã não identifica como elemento interativo e não é possível identificar se o acordeão está aberto ou fechado

    URLs a verificar

    Recomendações

    • Verificar a estrutura de todos os acordeões do website.
    • Definir o acordeão semanticamente como um botão, garantindo que o seu título é atribuído como um cabeçalho apropriado.
    • É necessário informar as tecnologias de apoio sobre o estado do acordeão (aberto ou fechado). Para esse efeito, deve ser utilizado o atributo aria-expanded em conjunto com JavaScript.

  • issue #84 Tab estruturada 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

    Evidências
    Existe um componente tab que não está estruturado de forma adequada. Para além de não ser possível identificá-lo como um tabulador através de leitores de ecrã, existem outros aspetos que deveriam ser implementados para garantir o seu correto funcionamento com o teclado e leitores de ecrã.

    Leitor de ecrã não identifica como um tabulador(separador) e não é possível fazer o salto para o conteúdo apresentado

    Image

    Exemplo de construção de uma tab pela W3C que indica que as opções são tabuladores e o número de opções disponíveis

    Leitor de ecrã não informa que está dentro do conteúdo do tabulador (painel de separador)

    Image

    Exemplo de construção de uma tab pela W3C indica que é um tabulador, o número de opções e o painel do separador e é possível fazer o salto para o conteúdo com a tecla TAB

    URLs a verificar

    Recomendações

    • É necessário garantir que o tabulador seja construído de forma adequada. Para isso, utilizem os atributos ARIA role="tablist", role="tab" e role="tabpanel", para indicar aos leitores de ecrã que se trata de um tabulador.
    • Para garantir uma interação apropriada, utilizem aos atributos aria-selected, aria-controls, em conjunto com JavaScript.
    • Para mais informações partilhamos o exemplo de construção de TAB da W3C e documentação sobre as propriedades role="tab"

  • issue #69 O leitor de ecrã identifica mais opções do que é apresentado visualmente no carrossel

    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

    Evidências
    O carrossel existente na secção “agenda” da página inicial do Município de Oliveira do Bairro apresenta três elementos visualmente. No entanto, os dezassete elementos do carrossel aparecem visíveis para os leitores de ecrã.

    Image

    Carrossel que mostra todos os itens aos leitores de ecrã
    Para além disso, na lista de dezassete itens, os cinco primeiros elementos são iguais aos cinco últimos, e portanto são anunciados em duplicado pelo leitor de ecrã.

    Recomendações
    Recomendamos que os elementos mostrados aos leitores de ecrã sejam exatamente aqueles que são mostrados visualmente de cada vez, para que os utilizadores destas tecnologias tenham a mesma experiência de navegação dos demais utilizadores.
    Recomendamos ainda a restruturação dos itens do carrossel, nomeadamente à remoção dos itens repetidos.

    Para mais informações é possível consultar os artigos Carousel Structure e Carousel (Slide Show or Image Rotator) Pattern do W3C.

  • issue #56 Carrosséis que exibem conteúdos automaticamente e não permitem pausar

    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

    Evidências:
    O carrossel existente na secção “agenda” da página inicial do Município de Oliveira do Bairro não permite pausar a passagem dos elementos.

    Image

    Elementos do carrossel da secção agenda

    Para além disso, não informam quantos itens fazem parte do carrossel,

    Recomendações:
    Recomendamos que seja indicado visualmente o número de elementos de cada carrossel, e que a navegação seja exclusivamente controlada pelo utilizador, que, para além de um botão que permita pausar a passagem dos itens, pode incluir também dois botões para avançar e retroceder,.
    Para mais informações é possível consultar os artigos Carousel Structure e Carousel (Slide Show or Image Rotator) Pattern do W3C.

  • issue #55 Faixas de avisos que exibem conteúdos automaticamente e não permitem pausar

    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

    Descrição do problema:

    Os itens da secção avisos presente na página inicial de Matosinhos estão sempre a passar e não permitem pausa.

    Image
    Websites que necessitam de correções (NOK):

    O referido acima e os seguintes:

    Websites que estão a cumprir (OK):

    Não foi identificado a faixa de aviso nos seguintes websites:

    Sugestão de correção

    Recomendamos a inclusão de um botão para que seja pausada a passagem dos itens na secção avisos em todos os sites.

  • issue #4 O conteúdo do glossário não está estruturado como uma lista de definição

    etiqueta: chk 10 webetiqueta: melhoriaetiqueta: 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](https://amagovpt.github.io/kit-selo/checklists/checklist-10aspetos#n83

    Evidências
    Verifica-se que existem conteúdos que não estão estruturados como listas:

    Recomendações

  • issue #3 Não é possível distinguir as diferentes navegações da página com o leitor de ecrã

    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](https://amagovpt.github.io/kit-selo/checklists/checklist-10aspetos#n83

    Evidências

    Quando uma página possui mais de uma área de navegação, é importante nomear cada nav par que os utilizadores de leitores de ecrã entendam a finalidade de cada navegação.

    A navegação está dividida entre o menu principal e o menu lateral. Nestes casos, e de acordo com as recomendações, ambas as áreas de navegação encontram-se corretamente estruturadas com o elemento nav. No entanto, torna-se agora necessário nomeá-las de forma adequada, de modo a permitir a sua distinção e identificação clara.

    URLs a verificar
    https://www.cm-olb.pt/municipio - todas as páginas internas

    Recomendações

    • O menu principal e o lateral devem ser nomeados de uma forma que seja possível distingui-los. Para isso, podem utilizar o aria-label no nav.

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #5 Ao desligar o CSS existe perda de informações

    etiqueta: chk 10 webetiqueta: NOKetiqueta: R 8.4

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

    Evidências
    O título "Galeria selecionada" está sendo inserido via CSS e isso faz com que não seja apresentado quando alteramos ou removemos o CSS:

    Título "Galeria selecionada" está sendo apresentado na página

    O título "Galeria selecionada" não é visível quando desliga o CSS

    URLs a verificar

    Recomendações
    Textos que comunicam informação — como títulos, subtítulos ou rótulos — devem ser apresentados estruturalmente no HTML, e não apenas através de CSS.

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: N/A

Lista de evidências recolhidas:

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: N/A

Lista de evidências recolhidas:

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: N/A

Lista de evidências recolhidas:

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

etiqueta: N/A

Lista de evidências recolhidas:

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

etiqueta: NOK

Lista de evidências recolhidas:

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 2.1 - O tipo de letra do corpo do documento é adequado e o tamanho da letra é, no mínimo, de 12 pontos

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

Lista de evidências recolhidas:

  • issue #2 Menu lateral com tamanho de fonte abaixo do recomendado

    etiqueta: melhoriaetiqueta: chk conteúdoetiqueta: R 2.1

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

    Evidências
    Embora o menu principal utilize um tamanho mínimo de 16px, ele está a apresentar apenas as opções de 1.º e 2.º nível. As restantes opções são disponibilizadas no menu lateral, que assume assim o papel de principal meio de navegação para aceder às demais subopções.

    Verifica-se que o menu lateral possui tamanho de fonte de 15.2px:

    URLs a verificar

    Recomendações
    Ajustar o tamanho da fonte das opções do menu lateral para que seja 16px.

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

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

Lista de evidências recolhidas:

  • issue #33 Estrutura do menu lateral não é percetível

    etiqueta: melhoriaetiqueta: chk conteúdoetiqueta: R 3.2

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

    Evidências
    Verificámos que, no Sítio Oficial da Câmara Municipal de Oliveira do Bairro, foram incluídos menus laterais nas páginas de interior. Notámos que, visualmente, estes menus não tornam evidente a estrutura hierárquica da navegação, dificultando a perceção do nível em que o utilizador se encontra e da sua localização dentro do site.

    Image

    Figura - Menu lateral da página de interior Estrutura do Conselho Local de Ação Social (CLAS).

    URLs a verificar
    Todas as páginas de interior com menus laterais.

    Recomendações
    Deve ser feita uma revisão da estrutura do menu de forma a tornar a hierarquia mais clara, melhorar a identificação do nível de navegação e garantir que o utilizador compreende facilmente onde está e para onde pode ir a seguir.

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #31 As hiperligações não se diferenciam do texto envolvente

    etiqueta: NOKetiqueta: R 3.3etiqueta: chk conteúdo

    As hiperligações de texto não devem ser diferenciadas apenas com base na cor.
    – ver requisito 3.3 na lista Conteúdo

    Notas gerais
    As hiperligações devem ter uma representação visual diferente do texto envolvente. Para além da cor, deve ser utilizado outro elemento diferenciador com base na forma, como por exemplo, sublinhado, negrito, com um ícone, fundo ou delineado, para que seja percecionada como clicável, nomeadamente por pessoas com daltonismo.

    Evidências
    Verificámos que, nas páginas do Sítio Oficial da Câmara Municipal de Oliveira do Bairro, as hiperligações não têm diferenciação suficiente do texto envolvente.

    Image

    Figura – Página Declaração de Acessibilidade e Usabilidade.

    URLs a verificar
    Esta recomendação deve ser aplicada em todas as hiperligações do site.

    Recomendações
    Recomendamos diferenciar as hiperligações do texto envolvente com base na cor e na forma (idealmente, colocar sublinhado) e garantir que o sublinhado aparece por defeito e não apenas quando se passa o rato por cima da hiperligação.

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:

  • issue #16 Documentos longos sem índice e acordeões mal estruturados

    etiqueta: NOKetiqueta: R 4.1etiqueta: chk conteúdo

    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:
    A página “Rede Social” com conteúdo longo possui acordeões que substituem o índice. O uso de acordeões como substituição de um índice é uma solução válida, mas é importante ter em consideração alguns aspetos essenciais para garantir a acessibilidade. Os acordeões presentes na página devem ser corrigidos pois não estão estruturados corretamente, sendo assim o leitores de ecrã não identificam se o componente está expandido ou recolhido. Sendo assim, os utilizadores podem saltar informações úteis e não perceber o conteúdo que está ali.

    URLs a verificar

    Recomendações

    Recomendamos rever os acordeões do website para garantir que sejam estruturados corretamente. Para isso, recomendamos consultarem as notas partilhadas no Requisito 8.3 da checklist dos 10 aspectos.

Requisito 4.2 - O layout do sítio Web é adaptável a plataformas móveis sem necessidade de efetuar varrimento horizontal

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #15 O layout do sítio Web é adaptável a plataforma móveis

    etiqueta: NOKetiqueta: chk conteúdoetiqueta: R 4.2

    O layout do sítio Web é adaptável a plataformas móveis sem necessidade de efetuar varrimento horizontal.
    – ver requisito 4.2 na lista Conteúdo

    Evidências

    O layout do site deve ter comportamento responsive, ou seja, deve-se adaptar às diferentes resoluções de ecrãs, de forma a garantir que a navegação seja fluída e não haja conteúdo cortado.

    • Na evidência (1) o elemento interativo do carrossel, não se adapta às diferentes resoluções, apresenta-se cortado na versão mobile. Sendo assim, é necessário rever e corrigir espaçamento e margens responsivas das áreas clicáveis.
    Erro de responsividade no website Oliveira do Bairro
    URLs a Verificar

    Recomendação

    Garantir que todo o layout do site, especificamente elementos interativos como as setas interativas do carrossel, e verificar se possuem comportamento responsive e adaptam-se às diferentes resoluções de ecrã, sem necessidade de fazer varrimento horizontal para realizar a leitura dos conteúdos.

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #14 Existem elementos interativos acionados apenas com a passagem do rato (hover)

    etiqueta: NOKetiqueta: chk conteúdoetiqueta: R 5.1

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

    Evidências

    • Não devem existir elementos de interação, como hiperligações ou botões, que aparecem apenas quando se passa por cima com um dispositivo apontador. Este método de interação não está disponível em aparelhos com interação por toque.

    A evidência (1) indica que, na página inicial, o chatbot é acionado apenas através da interação por hover. Ao passar o rato, surge a mensagem “Fale connosco – Precisa de ajuda?”. No entanto, quando um elemento interativo depende exclusivamente do hover para ser ativado ou para revelar informação, torna-se inacessível para utilizadores que recorrem a tecnologias de apoio, bem como para quem utiliza dispositivos móveis baseados em toque. Esta limitação compromete a perceção da funcionalidade e impede o acesso equitativo ao serviço disponibilizado. (Figura 1)

    Image

    Figura 1 - Chatbot acionável apenas com hover não recebe foco do teclado e leitor de ecrã

    URLs a verificar

    Recomendação

    Garantir que o chatbot pode ser acionado por diferentes métodos de interação incluindo teclado, toque e tecnologias de apoio e que a mensagem associada é apresentada de forma visível e acessível sem depender exclusivamente do hover. (Ver nota do Requisito 8.3 - 10 Aspetos)

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #13 Os elementos interativos têm uma dimensão mínima de 44px

    etiqueta: NOKetiqueta: chk conteúdoetiqueta: R 5.2

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

    Evidências

    • Para garantir que os utilizadores interagem devidamente com um elemento interativo (botões, imagens-link...), a área clicável desse elemento deve ser, no mínimo, 44px de largura e 44px de altura.

    A evidência (1) revela que na página “Município”, há elementos interativos com área clicável inferior ao recomendado. Por exemplo, o botão do menu lateral, na opção “Recursos humanos” com 42.23px de altura. Assim como as imagens link do rodapé, que possuem tamanho inferior ao recomendado por exemplo os botões “Deixe sua mensagem”, “234 732 100” e “Subscreva a Newsletter” com 7.83px de largura e 20px de altura, não cumprindo as dimensões mínimas necessárias. (Figura 1)

    Elementos interativos não cumprem valor mínimo recomendado

    Além disso, existem outros elementos interativos no website por exemplo o botão “Pesquisar” com dimensão (26px de altura e largura) inferior ao tamanho mínimo recomendado. (Figura 2)

    Botão “Pesquisar” com dimensão inferior ao recomendado

    URLs a verificar

    Recomendações
    Devem garantir que os elementos interativos têm uma altura e largura igual ou superior a 44px de área clicável, mesmo que o ícone/imagem tenha um tamanho inferior.

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #12 Há apenas um botão de ação principal por página e o mesmo encontra-se destacado

    etiqueta: NOKetiqueta: chk conteúdoetiqueta: R 5.3

    Há apenas um botão de ação principal por página e o mesmo encontra-se destacado.
    – ver requisito 5.3 na lista Conteúdo

    Evidências

    • Os botões de ação principal devem estar destacados numa página ou num bloco de informação para tornar mais perceptível o local onde os utilizadores devem clicar para realizar uma determinada tarefa.

    A evidência (1) revela que na página inicial existem botões principais e secundários com o mesmo estilo, por exemplo nas secções “em foco” e “acessos rápidos”. Os botões secundários, ou elementos da interface devem estar menos destacados e com um estilo diferente dos botões de ação principal. Ao garantirmos uma hierarquia dos botões, reduzimos a probabilidade de ações secundárias serem confundidas com ações principais.

    Image

    Figura 1 - Botões sem diferenciação de estilos para ações primárias e secundárias

    A evidência (2) revela que na página “Newsletter” existem dois botões principais com o mesmo estilo. Os botões secundários devem estar menos destacados e com um estilo diferente. Ao garantirmos uma hierarquia dos botões, reduzimos a probabilidade de ações secundárias serem confundidas com ações principais. É necessário destacar o botão “Submeter” como a ação primária do fluxo desta página.

    Image

    Figura 2 - Botão de ação principal não encontra-se destacado

    URLs a verificar

    Recomendação geral
    Os botões principais devem ser estilizados de forma diferente dos botões de ação secundária. Pode-se também distinguir os botões através da forma (ex: preenchimento, delineamento, cantos arredondados).

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #11 Elementos interativos devem aparentar ser clicáveis

    etiqueta: NOKetiqueta: chk conteúdoetiqueta: R 5.4

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

    Evidências

    A evidência (1) revela que na página inicial há elementos interativos, como os cards de eventos e notícias, que têm um estilo não aparenta ser clicável, visto que a única indicação de que é clicável é a alteração do cursor. Rever o estilo dos elementos interativos para que seja mais percetível que são clicáveis. (Figura 1)

    Image

    Figura 1 - Elementos interativos que não possuem indicação visual de interatividade

    Na página Rede Social identificamos que o botão “Voltar ao topo” não possui contraste suficiente. Sendo assim, pode não ser percetível como clicável. O mesmo problema acontece nas combinações de cores do campo de pesquisa da página, em que o elemento gráfico da busca na cor #FFFFFF em relação ao plano de fundo #E8F0FE não passa na avaliação de contraste. (Figura 2 e 3)

    Image

    Figura 2 - Problema de contraste em botão “Voltar ao Topo”

    Image

    Figura 3- Problema de contraste em botão “Pesquisar”

    Além disso, nas páginas Farmácias do Concelho e Ligações Úteis existem componentes que não aparentam ser clicáveis, apesar de estarem estruturados como elementos interativos, sendo essa perceção apenas possível ao passar o cursor (hover). Para que sejam claramente identificados como elementos interativos e não apenas como texto, é necessário que apresentem um contorno visível e um estilo consistente que não desapareça na ausência de hover. (Figura 4)

    Image

    Figura 4 - “Pesquisar Farmácia de Serviço” não aparenta ser clicável

    URLs a verificar

    Recomendações

    • Os elementos interativos devem ter um estilo que demonstre que são clicáveis e, ao mesmo tempo, suficientemente diferente de elementos não clicáveis para que não se confundam. recomenda-se a utilização de contornos, variações de relevo ou outras diferenciações visuais que reforcem a perceção do seu caráter interativo.
    • O contraste em elementos interativos deve ser de, no mínimo, 3:1 em relação a cor adjacente. Este contraste é aplicado a todos os estados dos elementos (normal, hover, focus, etc). Quando o elemento possui conteúdo em texto, o contraste deve ser de no mínimo, 4,5:1 com a cor de fundo.

Checklist Transação

etiqueta: NOK

Nível de conformidade:

  • Checklist Transação: 45.5% (5/11)
    • Requisitos avaliados: 13 (2 N/A excluídos, 11 aplicáveis)
    • Requisitos OK: 5
    • Requisitos NOK: 6
    • Requisitos N/A: 2

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

etiqueta: NOK

Lista de evidências recolhidas:

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

    etiqueta: chk transaçãoetiqueta: R 1.2etiqueta: NOK

    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:

    • Em formulários longos, com mais de 2 ecrãs de altura, deve-se garantir que a informação é pedida ao utilizador de forma faseada, dividindo os passos em várias páginas ou secções. No caso de formulários curtos, não é necessário fazer esta divisão.

    Na página Formulário de Avaliação, existe um formulário longo com mais de 2 ecrãs, onde é pedida toda a informação ao utilizador de uma só vez.

    Image

    Figura 1 – Formulário extenso que exige scroll ao longo de mais de cinco ecrãs

    URLs a verificar

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

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

etiqueta: N/A

Lista de evidências recolhidas:

  • issue #27 Não existem formulários com mais de uma página

    etiqueta: chk transaçãoetiqueta: R 1.3etiqueta: N/A

    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:
    O requisito não é aplicável, uma vez que não encontramos formulários com mais de uma página. Sendo assim o requisito será “Não Aplicável”. (N/A)

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

etiqueta: NOK

Lista de evidências recolhidas:

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

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

    Evidências:
    Verificámos que os campos “Número de Identificação Fiscal” e “Morada”, do formulário da página Novo Registo de Munícipe, são demasiado largos para o tipo de informação a inserir.

    O Número de Identificação Fiscal tem 9 dígitos, pelo que não necessita de um campo tão extenso. Da mesma forma, o campo Morada é apresentado com uma largura maior do que a necessária para facilitar a leitura e o preenchimento.

    URL a verificar:
    Página Novo Registo de Munícipe - Especificamente os campos “Número de Identificação Fiscal” e “Morada”.
    Estes campos aparecem tanto quando o utilizador seleciona “Sou uma Pessoa Singular” como quando escolhe “Sou outro tipo de Entidade”. Em ambos os casos, os mesmos campos são apresentados e devem ser verificados.

    Recomendações:
    Recomendamos ajustar a largura dos campos do formulário para que corresponda ao conteúdo esperado.

    Image

    Figura - Campos "Número de Identificação Fiscal" e "Morada" no formulário da página Novo Registo de Munícipe.

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #25 Há campos dependentes de outros campos que estão imediatamente disponíveis para preenchimento

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

    Evidências:
    No formulário da página Novo Registo de Munícipe, verificámos que os campos “Concelho” e “Freguesia” ficam imediatamente disponíveis para preenchimento, apesar de, por defeito, não apresentarem qualquer opção. Contudo, estes campos são dependentes de escolhas anteriores:
    • O campo Concelho depende da seleção feita no campo “Distrito” e só deve apresentar opções depois de o utilizador escolher um distrito.
    • O campo Freguesia depende da seleção feita no campo “Concelho” e só deve apresentar opções depois de o utilizador escolher um concelho.

    Image

    Figura - Campos "Distrito", "Concelho" e "Freguesia" no formulário da página Novo Registo de Munícipe.

    URL a verificar:
    Página Novo Registo de Munícipe - Especificamente os campos “Concelho” e “Freguesia”.
    Estes campos aparecem tanto quando o utilizador seleciona “Sou uma Pessoa Singular” como quando escolhe “Sou outro tipo de Entidade”. Em ambos os casos, os mesmos campos são apresentados e devem ser verificados.

    Recomendações:
    Tendo em conta estas dependências, recomendamos que os campos dependentes apenas sejam apresentados após o utilizador preencher o campo do qual dependem. Até esse momento, devem permanecer ocultos, tanto na interface gráfica como para tecnologias de apoio, evitando confusão e garantindo uma experiência mais acessível.

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

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

Lista de evidências recolhidas:

  • issue #24 O atributo placeholder está a substituir visualmente o rótulo

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

    Evidências:
    No campo de pesquisa geral, localizado no topo do site, verificámos que o atributo placeholder está a substituir visualmente o rótulo do campo. O texto apresentado como placeholder— “Pesquisar conteúdos na plataforma inteira” — aparece dentro do campo e funciona, na prática, como se fosse o rótulo.

    Apesar de existir um elemento label associado ao campo (<label for="mega_pesquisa_input_2">Pesquisar conteúdos na plataforma inteira</label>), este rótulo não é visível na interface gráfica e está disponível apenas para tecnologias de apoio, como leitores de ecrã.

    Image

    Figura - Análise do campo de pesquisa geral, no topo do site, através do Google Inspector.

    Componentes a verificar:
    Campo de pesquisa geral no topo do site.

    Recomendações:
    Recomendamos que o rótulo do campo seja apresentado de forma visível na interface gráfica, e não apenas para leitores de ecrã.

    Recomendamos também que o texto do rótulo do campo de pesquisa seja mais claro e direto. Neste caso, uma solução adequada seria, por exemplo, utilizar simplesmente “Pesquisar” como rótulo.

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #124 Há campos obrigatórios que não estão visualmente identificados

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

    Campos obrigatórios devem ser claramente indicados como tal.
    – ver requisito 2.4 na lista Transação

    Evidências:
    No campo “Número de Documento de Identificação”, presente quando se seleciona a opção “Sou uma Pessoa Singular”, no formulário da página Novo Registo de Munícipe, não há uma indicação visual de que se trata de um campo de preenchimento obrigatório.

    Image

    Figura - Análise do campo "Número de Documento de Identificação", no formulário da página Novo Registo de Munícipe, através do NVDA. Feedback do leitor de ecrã está evidenciado através de um retângulo de borda preta.

    URL a verificar:
    Novo Registo de Munícipe - Quando o utilizador seleciona a opção “Sou uma Pessoa Singular” – Campo “Número de Documento de Identificação”.

    Recomendações:
    Pode-se colocar um * no campo obrigatório, desde que o significado do * seja mencionado no início do formulário.
    Uma outra possível solução é adicionar a descrição “(obrigatório)” ou “(campo obrigatório)” em frente aos rótulos dos campos obrigatórios.

  • issue #123 Uso incorreto do atributo 'required'

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

    Campos obrigatórios devem ser claramente indicados como tal.
    – ver requisito 2.4 na lista Transação

    Evidências:
    Verificámos que, no formulário de Subscrição de Newsletter, o campo obrigatório “Email” utiliza a expressão required="required" dentro do elemento <input> para indicar programaticamente que o campo é obrigatório.
    Embora alguns leitores de ecrã consigam interpretar esta indicação, esta forma de declarar a obrigatoriedade não é semanticamente correta e pode não ser reconhecida por outras tecnologias de apoio.

    Image

    Figura - Análise do campo "Email", no formulário da página Subscrição de Newsletter, através do Google Inspector. A expressão required="required" está destacada através de um retângulo de borda preta.

    URL a verificar:
    Subscrição de Newsletter

    Recomendações:
    Sugerimos substituir a expressão required="required" pelo atributo required. O uso do atributo required segue a especificação HTML, assegura uma marcação semanticamente correta e garante uma maior compatibilidade com diferentes tecnologias de apoio.

    Deixamos também aqui o questionamento se, tratando se este formulário de um formulário com apenas um campo — o campo Email — existe realmente necessidade de o marcar como obrigatório.

  • issue #122 Obrigatoriedade não declarada através de atributo 'required'

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

    Campos obrigatórios devem ser claramente indicados como tal.
    – ver requisito 2.4 na lista Transação

    Evidências:
    Verificámos que, nos campos obrigatórios dos formulários das páginas Login e Novo Registo de Munícipe, a indicação programática de obrigatoriedade não é feita através do atributo required. Atualmente, a obrigatoriedade é comunicada apenas através de elementos visuais e de texto adicional, mas não através do mecanismo padrão de HTML que permite aos navegadores e às tecnologias de apoio identificar automaticamente que um campo é obrigatório.

    Image

    Figura 1 - Análise dos campos de formulário da página Login através do Google Inspector.

    Image

    Figura 2 - Análise dos campos de formulário da página Novo Registo de Munícipe através do Google Inspector.

    URLs a verificar:
    Login – Campos:

    • Email/Username
    • Palavra-Passe

    Novo Registo de Munícipe - Quando o utilizador seleciona a opção “Sou uma Pessoa Singular” – Campos:

    • Nome Completo
    • Email
    • Palavra-Passe
    • Confirmação da Palavra-Passe
    • Data de nascimento
    • Telemóvel
    • Número de Documento de Identificação
    • Data de validade do Documento de Identificação
    • Número de Identificação Fiscal
    • Morada
    • Código Postal
    • Localidade

    Novo Registo de Munícipe - Quando o utilizador seleciona a opção “Sou outro tipo de Entidade” – Campos:

    • Nome Completo
    • Email
    • Palavra-Passe
    • Confirmação da Palavra-Passe
    • Data de nascimento
    • Telemóvel
    • Número de Identificação Fiscal
    • Morada
    • Código Postal
    • Localidade

    Recomendação:
    Recomendamos que, em todos os campos de preenchimento obrigatório, a indicação programática de obrigatoriedade seja feita utilizando o atributo required, garantindo assim maior consistência e suporte por tecnologias de apoio.

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

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

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

    Evidências
    Verificámos que à frente dos rótulos dos campos dos formulários presentes nas páginas Login, Subscrição de Newsletter e Novo Registo de Munícipe está um asterisco (“*”). No entanto, não é fornecida uma legenda clara sobre o significado do asterisco no formulário.

    Image

    Figura 1 - Formulário da página Login.

    Image

    Figura 2 - Formulário da página Subscrição de Newsletter.

    Image

    Figura 3 - Formulário da página Novo Registo de Munícipe.

    URLs a verificar:

    Recomendações:
    Recomendamos que seja adicionada uma legenda no início do formulário que indique claramente o significado de *.
    Uma outra possível solução é adicionar a descrição “(obrigatório)” ou “(campo obrigatório)” em frente aos rótulos dos campos obrigatórios.

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

etiqueta: N/A

Lista de evidências recolhidas:

  • issue #19 As ações destrutivas nunca devem ser permanentes

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

    Não foi identificado no website formulários que permitem realizar ações destrutivas. Por esse motivo, consideramos o critério como "Não aplicável".

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #125 Existem mensagens de topo que não remetem o foco para os campos rspetivos

    etiqueta: chk transaçãoetiqueta: melhoriaetiqueta: R 4.3

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

    Verifica-se que no Elogios/Reclamações/Sugestões está sendo apresentado mensagens de erro junto ao campo do formulário que estão associadas ao seu respectivo campo. Para além disso, é apresentado uma lista sumário com as mensagens de erro no topo do formulário:

    Image

    No entanto, quando clicamos na opção "Mensagem" da lista sumário verifica-se que o foco não está sendo posicionado corretamente no seu respetivo campo e que precisa ser corrigido:

  • issue #18 Existência de mensagens de erro não associadas programaticamente aos respetivos campos

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

    As mensagens de erro do formulário Novo Registo de Munícipe não estão associadas programaticamente aos respetivos campos:

    Image

    Exemplo de mensagem de erro não associada programaticamente ao respetivo campo

    Recomendamos que as mensagens de erro sejam associadas programaticamente aos campos, para que os utilizadores que navegam por teclado (tab e shift+tab) e leitor de ecrã possam ouvi-las à medida que o foco passa pelos mesmos.
    A associação programática de uma mensagem de erro a um campo pode fazer-se adicionando dois atributos a esse campo:

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

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #17 As mensagens de erro devem mostrar os passos concretos para a resolução dos mesmos

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

    Evidências

    A mensagem de erro “Email é inválido Email não foi verificado corretamente ou ocorreu um erro ao validar a verificação!” presente no formulário Novo Registo de Munícipe não ajuda no preenchimento do campo:

    Image

    Figura 1 - Mensagem de erro que não guia o utilizador na resolução do erro

    Como observado na figura, a mensagem “Email é inválido Email não foi verificado corretamente ou ocorreu um erro ao validar a verificação” 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.

    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.

Outras violações

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

Lista de evidências recolhidas:

  • issue #98 Outras violações - Menu de navegação: o foco do leitor de ecrã retorna para o início após carregamento "automático" de página

    etiqueta: melhoriaetiqueta: outras violações

    Evidências
    Verifica-se que, em determinados momentos durante a navegação no website, ocorre um recarregamento automático da página quando que é feita alguma ação, como, por exemplo, a seleção de uma subopção no menu lateral. Esta situação provoca o retorno do foco do leitor de ecrã para o início da página, o que pode gerar frustração ao utilizador, uma vez que este terá de percorrer novamente todo o conteúdo para regressar à posição anterior e prosseguir com a sua interação. Isso pode estar a acontecer porque cada interação com o menu é carregado uma nova página com outra URL:

    URLs a verificar
    https://www.cm-olb.pt/municipio - todas a páginas internas que está sendo apresentado o menu lateral

    Recomendações

    • Para garantir que o foco não se perca, é necessário estruturar as opções do menu na árvore e evitar o uso do AJAX.
    • Ao abrir uma opção do menu, não deve existir um carregamento para uma nova url pois isso força o foco a retornar para o início.
    • Devem corrigir o problema mencionado na issue #92 pois são problemas relacionados entre si.

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

    etiqueta: melhoriaetiqueta: outras violações

    Evidências
    Verificámos uma quebra de layout nos elementos interativos da paginação. Por exemplo nas páginas interiores das Notícias (a partir da página 6) onde a componente de paginação se apresenta desformatada . (Figura 1)

    Image

    Figura 1 – Exemplo de quebra de Layout apenas em páginas interiores

    URLs a verificar

    Recomendações

    Recomenda-se a definição de limites consistentes de largura e extensão para a componente de paginação, garantindo a sua apresentação uniforme em todas as páginas.
    Adicionalmente, deve ser assegurado um comportamento responsivo adequado, nomeadamente no tratamento da quebra de texto em títulos e elementos adjacentes, de forma a preservar a legibilidade, a integridade do layout e a acessibilidade global da página.

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

    etiqueta: melhoriaetiqueta: outras violações

    Descrição da problemática

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

    Durante a navegação sequencial através da tecla TAB, há algumas componentes que não apresentam o foco visível que auxilia a navegação de utilizadores por teclado. Por exemplo na página inicial a secção Agenda e o rodapé de todo website com problemas de foco (Figura 1 e 2)

    Image

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

    Image

    Figura 2 - Foco não visível no rodapé da página Conctactos

    Em alguns momentos o foco não é apresentado de forma perceptível, sendo apenas possível inferir a sua existência através da barra de estado do navegador, o que não constitui uma solução acessível nem adequada. Sendo assim não é possível identificar visualmente a posição do utilizador em cada momento da navegação. Esta situação pode levar o utilizador a perder a noção da sua posição na página, comprometendo a usabilidade e a acessibilidade do website.

    URLs a verificar

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

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

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

  • issue #7 Outras violações- Páginas sem conteúdo e com erros de disponibilização

    etiqueta: melhoriaetiqueta: outras violações

    Evidências:

    A página https://www.cm-olb.pt/ficha-tecnica/indice-de-transparencia-municipal apresenta-se em branco, exibindo apenas a mensagem "Informação brevemente disponível". (Figura 1)

    Image

    Figura 1 - Páginas sem conteúdos

    A página Regulamento de Apoio às Freguesias apresenta a mensagem de erro “A pasta indicada não foi encontrada!”. (Figura 2)

    Image

    Figura 2 - Ausência de conteúdos disponíveis

    Adicionalmente, a página Regulamentos em Início de Procedimento surge em branco, não apresentando qualquer mensagem de erro ou indicação ao utilizador. (Figura 3)

    Image

    Figura 3 - Página em branco sem conteúdo útil

    URLs a verificar

    Recomendações
    Garantir que todas as páginas disponibilizam conteúdos válidos e atualizados ou em alternativa, apresentam mensagens de erro claras, informativas e consistentes. Sempre que um conteúdo não esteja disponível, deve ser fornecida ao utilizador uma explicação compreensível. Recomenda-se:

    • A implementação de mecanismos de validação e monitorização de conteúdos e ligações, de forma a prevenir páginas em branco, assegurando uma experiência de utilização coerente e acessível.
    • Nos casos em que as páginas não disponham de conteúdo relevante ou cuja disponibilização não esteja prevista a curto prazo, recomenda-se a sua remoção, evitando a apresentação de páginas vazias e reduzindo potenciais frustrações para os utilizadores.

Significado das etiquetas utilizadas