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

Introdução

O website https://www.cm-braganca.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 aspetos60.9% (14/23)etiqueta: Não passa
Conteúdo58.8% (10/17)etiqueta: Não passa
Transação75.0% (6/8)etiqueta: Passa

Nota: para passar os requisitos do Selo é necessário alcançar um nível de conformidade superior ou igual a 75% em cada uma das 3 checklists.

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

Declaração de Acessibilidade

etiqueta: NOK

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

Lista de evidências recolhidas:

Avaliação automática

etiqueta: NOK

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

Lista de evidências recolhidas:

Avaliação manual

etiqueta: NOK

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

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

Checklist 10 aspetos

etiqueta: NOK

Nível de conformidade:

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

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

etiqueta: NOK

Lista de evidências recolhidas:

  • evidência: issue #93 Não é possível identificar qual opção está com foco pelo teclado

    etiqueta: R 1.2etiqueta: chk 10 webetiqueta: melhoria

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

    Evidencias
    Ao navegar pelas opções do menu utilizando o teclado, através das teclas TAB e SHIFT + TAB, não é perceptível a posição actual do utilizador nos botões de subopções do menu.

    Image

    Não é visível que o foco está no botão de abrir a subopção de transparência

    URLs a verificar

    Recomendações

    • Definir um estilo visível para o contorno dos elementos interativos, utiizando à propriedade outline em CSS.
    • Outra alternativa, é manter o comportamento nativo dos navegadores, procedendo à remoção dos atributos de contorno actualmente definidos em CSS.
  • evidência: issue #92 Não é possível identificar se uma opção possui subopções, nem se estas se encontram expandidas ou recolhidas

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

    Image

    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.

    Opção "Ambiente e sustentabilidade" quando fechada não possui as subopções na estrutura DOM nem o atributo aria-controls

    Image

    Opção "Ambiente e sustentabilidade" quando aberta tem as subopções injetadas dinamicamente na estrutura DOM e apresenta o atributo aria-haspopup

    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.
    • Devem remover o atributo aria-haspopup que está sendo apresentado quando a opção é aberta

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:

  • evidência: issue #97 O ícone que indica as subopções do menu principal estão sendo inseridos via CSS

    etiqueta: R 1.3etiqueta: chk 10 webetiqueta: melhoria

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

    Evidências
    O menu principal do website da CM de Bragança apresentam imagens exibidas via CSS e o texto alternativo está sendo transmitido pelo aria-label:

    Ícone (▾) sendo apresentado via CSS

    Contudo, ao desligar o CSS não é possível identifica-lo corretamente pois o ícone desaparece e não é apresentado uma alternativa textual:

    URLs a verificar

    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 5.1 - A imagem ou gráfico tem um equivalente alternativo em texto curto e correto

etiqueta: NOK

Lista de evidências recolhidas:

  • evidência: issue #66 Há imagens com textos alternativos incorretos

    etiqueta: chk 10 webetiqueta: R 5.1etiqueta: NOK

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

    Evidências:

    • As imagens não decorativas deverão ter uma descrição breve associada, nomeadamente através do uso do atributo . Esta legenda deve descrever fielmente o propósito da imagem no contexto em que se encontra.
    • 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.

    Há imagens informativas que não possuem um texto alternativo. A evidência (1) apresenta o cartaz do evento de “Exposição Máscaras: Símbolos de Identidade” com uma imagem informativa com seu conteúdo disponível apenas visualmente, sendo assim, não contém a descrição completa do conteúdo em seu texto alternativo. (Figura 1)

    Image

    Figura 1 - Imagem com texto alternativo incompleto e sem descrição longa

    Na evidência (2) a imagem apresenta um texto alternativo incorreto. O conteúdo visual corresponde a uma micro central hidrelétrica, conforme descrito no parágrafo associado. Contudo, o texto alternativo informado é “Centro de Ciência Viva de Bragança”, o que não condiz com a imagem apresentada. (Figura 2)

    Image

    Figura 2 - Imagem com texto alternativo incorreto

    Na evidência (3) verificam-se, por exemplo, nas páginas interiores das Notícias, galerias de imagens sem texto alternativo ou com descrições incorretas, que não refletem o conteúdo visual apresentado. (Figura 3)



    Image

    Figura 3 - Galerias de fotos com texto alternativo incorreto, não descrevem o conteúdo das imagens

    URLs a verificar

    Recomendação
    Recomendamos alterar o texto alternativo da imagem para algo que descreva o conteúdo da imagem de forma sucinta. As imagens com função informativa, que complementam o conteúdo do website, devem incluir um texto alternativo que sirva de síntese do seu conteúdo e que seja lido pelo leitor de ecrã.

    • Evidência 02 - Sugestão de texto alternativo: alt="Micro central hidrelétrica do Centro de Ciência Viva"
    • Nota: É necessário rever todas imagens informativas do website, e assegurar que as boas práticas associadas ao requisito são aplicadas de forma consistente e transversal a todas as páginas do website e não apenas nos apontamentos aqui colocados.

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

etiqueta: NOK

Lista de evidências recolhidas:

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

    etiqueta: chk 10 webetiqueta: R 5.2etiqueta: NOK

    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) demonstra que os gráficos apresentados na página “Gestão de Energia” utilizam imagens complexas sem descrições alternativas completas. Embora exista algum texto embutido na imagem, este não é exposto de forma acessível, impedindo utilizadores de leitores de ecrã de compreender os valores representados. Por exemplo, no gráfico de distribuição da fatura de eletricidade, não é transmitido que “Iluminação Pública” corresponde a 62% do total. (Figura 1)

    Image

    Figura 1 - Imagens complexas sem descrições longas

    A mesma limitação ocorre nas imagens da evidência (2), onde os dados relativos à Iluminação Pública não são disponibilizados em formato textual. Esta falta de equivalentes textuais viola o presente requisito.

    URLs a verificar

    Recomendações

    Recomenda‑se disponibilizar uma descrição longa para cada gráfico, contendo todos os valores percentuais e categorias representadas, garantindo que a informação visual seja apresentada também em formato textual. Alternativamente, sempre que possível, os dados dos gráficos devem ser disponibilizados em HTML estruturado (listas ou tabelas), assegurando leitura completa por tecnologia

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

etiqueta: NOK

Lista de evidências recolhidas:

  • evidência: issue #51 Imagens-link com textos alternativos incorretos

    etiqueta: chk 10 webetiqueta: R 5.3etiqueta: NOK

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

    Evidências:

    • 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) demonstra o carrossel na secção “Os nossos sites” com links que possuem imagens que utilizam textos alternativos incorretos ou não descritivos. Estas imagens direcionam para páginas externas, mas os respetivos textos alternativos não indicam essa ação nem descrevem o conteúdo ou o destino do link.

    Por exemplo, na página inicial a imagem‑link “CPCJ” apresenta o texto alternativo alt="cpcj_1", que não transmite qualquer informação útil ao utilizador. Esta prática gera ruído na leitura por tecnologias de apoio e prejudica a compreensão da função das hiperligações. Os logotipos já possuem um título visível associado a imagem, por exemplo “GeoPortal”. Nesses casos, as imagens não acrescentam informação relevante e devem ser tratadas como decorativas, utilizando um texto alternativo vazio (alt="").

    Image

    Na evidência (2) há imagens link sem textos alternativos ou incorretos, como por exemplo os logotipos "ambiformed" com alt="6" e "Bragança Município" com alt="8" que não transmitem qualquer informação útil ao utilizador.

    Image

    URLs a verificar

    Recomendações
    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. Aplicar alt="" às imagens decorativas. E quando não forem decorativas, incluir um equivalente alternativo em texto que represente fielmente o destino da hiperligação. O texto alternativo deve transmitir claramente o destino ou finalidade do link.

    • Recomenda-se que, sempre que uma imagem ou ícone seja inserido exclusivamente via CSS (como é o caso do Botão pesquisar e dos links de partilha), seja incluído um texto em HTML no interior do botão, por exemplo através de um elemento , garantindo que a função do componente permanece disponível para tecnologias de apoio. Esse texto pode ficar visualmente oculto, mas deve continuar acessível a leitores de ecrã. Para mais informações: https://www.acessibilidade.gov.pt/tutorial/css-em-accao-conteudo-invisivel-apenas-para-utilizadores-de-leitor-de-ecra/#page1_topic_7
    • É necessário rever as boas práticas de acessibilidade em todas as páginas do website, 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.

Requisito 6.1 - No corpo de um documento, o rácio de contraste entre a cor do texto normal (menor que 18 pontos ou menor que 14 pontos negrito) e a cor do fundo é superior a 4,5:1

etiqueta: NOK

Lista de evidências recolhidas:

  • evidência: issue #68 Problemas de contraste para texto normal

    etiqueta: chk 10 webetiqueta: R 6.1etiqueta: NOK

    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

    • Contraste inferior para elementos textuais, elementos da interface e objetos gráficos.

    A evidência (1) apresenta o breadcrumb "Transparência" e “Comunicação”, que não satisfaz o requisito uma vez que as combinações de cor dos textos possuem um rácio de contraste inferior a 4.5:1 para texto normal. O mesmo acontece nas outras páginas que possuem breadcrumbs Município , Serviços e Participação (Figura 1)

    Image

    URLs a verificar

    Recomendações
    Recomendamos a revisão das cores das páginas e dos vários estados dos elementos para garantir os valores mínimos de contraste do texto normal

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

etiqueta: NOK

Lista de evidências recolhidas:

  • evidência: issue #112 Não há legendas nos reprodutores de multimédia

    etiqueta: chk 10 webetiqueta: R 7.2etiqueta: NOK

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

    Notas gerais:
    As legendas devem descrever todos os sons de um conteúdo multimédia que esteja a ser reproduzido (como música, efeitos sonoros e conversas). De preferência, as legendas devem poder ser ligadas e desligadas, como acontece nas legendas de filmes (ex: Netflix).

    Evidências:
    Verificámos que nos vídeos VÍDEO PROMOCIONAL e Vídeo QR2016 – presentes nas páginas Festival D'Onor e Quintanilha Rock 2016, respetivamente – não existem legendas nem transcrição textual dos conteúdos.

    Image

    Figura 1 – VÍDEO PROMOCIONAL disponível através do link “VIDEO PROMOCIONAL” na página Festival D'Onor.

    Image

    Figura 2 – Vídeo QR2016 disponível na página Quintanilha Rock 2016.

    URLs a verificar:

    Recomendações:
    Devem ser incluídas legendas fechadas no vídeo. Se não for possível garantir legendas, deve-se incluir uma transcrição textual do vídeo.

  • evidência: issue #111 O vídeo contém legendas abertas e a transcrição está incorreta

    etiqueta: chk 10 webetiqueta: R 7.2etiqueta: NOK

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

    Notas gerais:
    A utilização de legendas abertas em vídeos é uma forma eficaz de garantir que o conteúdo seja compreendido de outra forma além do áudio, permitindo que pessoas surdas ou com perda auditiva tenham acesso à informação apresentada. No entanto, este formato de legenda não oferece opções de personalização, como a alteração do tamanho da fonte, o que pode ser necessário para pessoas com deficiência visual. Adicionalmente, é fundamental que os vídeos forneçam uma transcrição textual das legendas, de modo que pessoas com deficiência auditiva e visual possam aceder ao conteúdo do vídeo através da leitura.

    Evidências:
    O vídeo Garanta a titularidade dos seus terrenos com o BUPi, da página Balcão Único do Prédio (BUPi), contém legendas abertas e a transcrição que é fornecida está incorreta.

    Image

    Figura - Vídeo Garanta a titularidade dos seus terrenos com o BUPi, da página Balcão Único do Prédio (BUPi). O vídeo apresenta legendas abertas e a transcrição em texto contém erros. Na imagem, um retângulo com borda preta destaca um desses erros na transcrição.

    URL a verificar:
    Página Balcão Único do Prédio (BUPi)

    Recomendações:
    Recomendamos que sejam fornecidas legendas fechadas para o vídeo. Estas legendas fechadas também podem servir de base para gerar uma transcrição correta do conteúdo.

  • evidência: issue #80 Segmento de vídeo não legendado

    etiqueta: chk 10 webetiqueta: R 7.2etiqueta: NOK

    Evidências:
    O vídeo Resumo :: Festival Literário de Bragança - 2022, disponível na página VI Festival Literário de Bragança | Resumo [VÍDEO], apresenta legendas fechadas sincronizadas, mas estas não estão completas ao longo de todo o conteúdo.

    Entre 04:17 e 05:25, durante a entrevista ao Presidente Municipal da Câmara de Bragança, as legendas deixam de aparecer, tornando essa parte do vídeo inacessível para quem depende desta tecnologia.

    Image

    Figura - Vídeo Resumo :: Festival Literário de Bragança - 2022, disponível na página VI Festival Literário de Bragança | Resumo [VÍDEO], com falta de legenda aos 04:23.

    URL a verificar:
    Página VI Festival Literário de Bragança | Resumo [VÍDEO]

    Recomendações:
    Recomendamos que as legendas fechadas estejam disponíveis e completas em todo o vídeo.

  • evidência: issue #78 As legendas fornecidas pelos vídeos são automáticas

    etiqueta: chk 10 webetiqueta: R 7.2etiqueta: NOK

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

    Notas gerais:
    As legendas automáticas fornecidas pelo Youtube, utilizam recursos de reconhecimento de voz que têm melhorado ao longo do tempo, no entanto, ainda enfrentam limitações que podem prejudicar a acessibilidade, como por exemplo, ela pode não ser fiel ao conteúdo que está a ser apresentado.

    Evidências:
    No vídeo Festival do Butelo e das Casulas & Carnaval dos Caretos 2025, presente na página Festival do Butelo e das Casulas & Carnaval dos Caretos, é possível ligar e desligar a legenda dos vídeos. No entanto, a legenda fornecida é automática, sendo necessário inserir uma legenda fechada para o vídeo.

    Image

    Figura - Vídeo Festival do Butelo e das Casulas & Carnaval dos Caretos 2025, presente na página Festival do Butelo e das Casulas & Carnaval dos Caretos, com legendas automáticas.

    URL a verificar:
    Página Festival do Butelo e das Casulas & Carnaval dos Caretos

    Recomendações:
    Recomendamos que sejam incluídas legendas fechadas. Caso a legenda que foi gerada automaticamente esteja boa, esta pode ser reaproveitada para gerar uma nova transcrição do conteúdo.

  • evidência: issue #77 Não existe audiodescrição do vídeo

    etiqueta: chk 10 webetiqueta: melhoriaetiqueta: R 7.2

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

    Notas gerais:
    Os vídeos que passam mensagens apenas percetíveis à visão devem conter uma audiodescrição, que é fundamental para que as pessoas cegas ou com baixa visão possam compreender o conteúdo exibido.

    Evidências:
    O vídeo futuro aeroporto regional, disponível na página Aeródromo, é uma simulação 3D do aeródromo de Bragança e transmite informação exclusivamente visual, tornando se inacessível para quem não vê.

    Image

    Figura - Vídeo futuro aeroporto regional disponível na página Aeródromo.

    URL a verificar:
    Página Aeródromo

    Recomendações:
    Recomendamos que seja adicionada uma audiodescrição do conteúdo.

  • evidência: issue #71 As legendas fornecidas pelo vídeo são automáticas

    etiqueta: chk 10 webetiqueta: melhoriaetiqueta: R 7.2

    Notas gerais:
    As legendas automáticas fornecidas pelo Youtube, utilizam recursos de reconhecimento de voz que têm melhorado ao longo do tempo, no entanto, ainda enfrentam limitações que podem prejudicar a acessibilidade, como por exemplo, ela pode não ser fiel ao conteúdo que está a ser apresentado.

    Evidências:
    No vídeo Inauguração da exposição "Casa de Férias", presente na página 'Casa de Férias' de Fernanda Fragateiro, é possível ligar e desligar a legenda dos vídeos. No entanto, a legenda fornecida é automática, sendo necessário inserir uma legenda fechada para o vídeo.

    Image

    Figura – Vídeo Inauguração da exposição “Casa de Férias”, presente na página 'Casa de Férias' de Fernanda Fragateiro, com legendas automáticas.

    URL a verificar:
    Página 'Casa de Férias' de Fernanda Fragateiro

    Recomendações:
    Recomendamos que sejam incluídas legendas fechadas. Caso a legenda que foi gerada automaticamente esteja boa, esta pode ser reaproveitada para gerar uma nova transcrição do conteúdo.

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

etiqueta: NOK

Lista de evidências recolhidas:

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

    etiqueta: chk 10 webetiqueta: R 8.2etiqueta: NOK

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

    Evidencia
    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, embora o menu esteja oculto através do CSS com o atributo display: none, ele continua visível juntamente com as restantes opções do menu principal:

    Embora o botão menu compacto esteja escondido via CSS através do display:none ele está a ser anunciado pelo leitor de ecrã dentro da navegação do menu principal

    Recomendações

    • 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".
  • evidência: issue #89 Existem elementos que estão a ser lidos apenas pelos leitores de ecrã

    etiqueta: chk 10 webetiqueta: R 8.2etiqueta: NOK

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

    Evidencia

    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:

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

    Recomendações

    • Relativamente ao campo de pesquisa, é necessário verificar todos os locais onde este é apresentado, garantindo que não é utilizada uma label associada a botões do tipo type="image".

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

etiqueta: NOK

Lista de evidências recolhidas:

  • evidência: issue #116 O breadcrumb não está estruturado com a semântica adequada

    etiqueta: chk 10 webetiqueta: R 8.3etiqueta: NOK

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

    Evidências:
    O componente breadcrumb do website está sendo estruturado como uma lista não ordenada:


    URLs a verificar

    Recomendações:

    • Estruturar o breadcrumb como uma lista ordenada, utilizando as tags ol e li.
  • evidência: issue #86 O chatbot e o componente de contactos/fale connosco não estão estruturados de forma apropriada

    etiqueta: chk 10 webetiqueta: R 8.3etiqueta: NOK

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

    Evidência

    Verifica-se que, em alguns websites, está a ser apresentado componentes flutuantes no rodapé, como o chatbot e componente de contactos/fale connosco. Eles estão construídos de forma inadequada, uma vez que são estruturadas como div em vez de elementos nativos do HTML.

    Por exemplo, na página inicial do website da CM de Bragança existe um chatbot que está acessível apenas pelo rato e está sendo construído com o uso de div:

    Chatbot construído com divs e está inacessível com o teclado e leitor de ecrã no website da CM de Bragança

    URLs a verificar

    Recomendação

    • Devem rever todos os websites que apresentem o chatbot e/ou componente flutuante no rodapé, como contactos/fale connosco.
    • Devem garantir que o chatbot ou outro componente fixo apresentado no rodapé 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.
  • evidência: issue #85 Existem acordeões construídos de forma inapropriada

    etiqueta: chk 10 webetiqueta: R 8.3etiqueta: NOK

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

    Evidencias

    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 se recorrer a elementos nativos do HTML.

    Por exemplo, no website da CM de Bragança existem acordeões que estão sendo estruturados como divs:

    Image

    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:

    Image

    Leitor de ecrã não identifica como elemento interativo e não é possível identificar se o conteúdo é possível de expandir ou fechar


    Outro exemplo acontece no acordeão da página Índice de Transparência Municipal em que o texto alternativo do acordeão está sempre acompanhado pela instrução "Clique para expandir", mesmo quando ele já está aberto:

    URLs a verificar

    Recomendação

    • 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.
    • Remover a instrução "Clique para expandir". Não devem inserir instruções adicionais para esse componente.
  • evidência: issue #69 O leitor de ecrã identifica mais opções do que é apresentado visualmente no carrossel

    etiqueta: chk 10 webetiqueta: R 8.3etiqueta: NOK

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

    Evidências:
    O carrossel presentes na secção "Os nossos sites" da página inicial da CM Bragança apresenta seis elementos visualmente. No entanto, os treze elementos do carrossel aparecem visíveis para os leitores de ecrã.

    Image

    Carrossel que mostra todos os itens aos leitores de ecrã

    Recomendações:
    Recomendamos que os elementos mostrados aos leitores de erã 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.

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

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

    etiqueta: chk 10 webetiqueta: R 8.3etiqueta: NOK

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

    Evidências:
    O carrossel presentes na secção "Os nossos sites" da página inicial da CM Bragança não permitem pausar a passagem dos elementos.

    Image

    Elementos do carrossel da secção "Os nossos sites"

    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 dos dois botões para avançar e retroceder, deve incluir um botão que permita pausar a passagem dos itens (caso não pretendam incluir o botão de pausa devem parar a progressão automática entre os itens).
    Para mais informações é possível consultar os artigos Carousel Structure e Carousel (Slide Show or Image Rotator) Pattern do W3C.

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

    etiqueta: chk 10 webetiqueta: R 8.3etiqueta: NOK

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

    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.

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

    etiqueta: chk 10 webetiqueta: R 8.3etiqueta: NOK

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

    Evidências:

    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 seção de navegação.

    No website da CM Bragança, tanto o menu principal como o menu lateral estão a ser anunciados como “navegação”. Desta forma, não é possível distingui-los corretamente:

    URLs a verificar

    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.

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:

  • evidência: issue #64 Não foram encontradas modais

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

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

    Evidências
    Não foram encontradas modais no site da Câmara Municipal de Bragança. Assim, este requisito é avaliado como “Não Aplicável” (N/A).

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:

  • evidência: issue #63 Não foram encontradas modais

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

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

    Evidências
    Não foram encontradas modais no site da Câmara Municipal de Bragança. Assim, este requisito é avaliado como “Não Aplicável” (N/A).

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:

  • evidência: issue #113 Não foram encontradas modais

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

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

    Evidências
    Não foram encontradas modais no site da Câmara Municipal de Bragança. Assim, este requisito é avaliado como “Não Aplicável” (N/A).

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:

  • evidência: issue #58 Não foram encontradas modais

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

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

    Evidências
    Não foram encontradas modais no site da Câmara Municipal de Bragança. Assim, este requisito é avaliado como “Não Aplicável” (N/A).

Checklist Conteúdo

etiqueta: NOK

Nível de conformidade:

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

Requisito 1.1 - O sítio Web apresenta um resumo breve do seu propósito, visível sem se fazer scroll

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

Lista de evidências recolhidas:

  • evidência: issue #47 O resumo do propósito está sendo apresentado parcialmente em algumas resoluções

    etiqueta: R 1.1etiqueta: melhoriaetiqueta: chk conteúdo

    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

    O critério está a cumprir, mas é possível fazer melhorias: o website apresenta o resumo do propósito na página inicial do website. Contudo, em algumas resoluções, como no tablet, o propósito está sendo apresentado parcialmente no ecrã, sendo necessário fazer scroll:


    URLs a verificar

    Recomendações

    • O resumo do propósito deve ser visto imediatamente na secção principal da página. Para isso, devem posicionar o resumo mais próximo ao topo.
    • Devem garantir que o resumo seja apresentado totalmente em todas as resoluções.

Requisito 2.1 - O tipo de letra do corpo do documento é adequado e o tamanho da letra é, no mínimo, de 12 pontos

etiqueta: NOK

Lista de evidências recolhidas:

  • evidência: issue #39 Etiquetas dos campos de preenchimento possuem tamanho abaixo do recomendado

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

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

    Evidencias

    As etiquetas dos formulários transmitem uma informação relevante para o utilizador durante o preenchimento, e verifica-se que elas estão com tamanho abaixo de 14,4px o que está abaixo do recomendado por ser uma informação primária:

    URLs a verificar

    Recomendações

    • É necessário rever todos os formulários e campos de pesquisa, assegurando que o tamanho das etiquetas (labels) seja, no mínimo, de 16 pixels.
    • O atributo font-size deve ser alterado diretamente na tag label.
  • evidência: issue #2 As subopções do menu possuem tamanho de texto abaixo do recomendado

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

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

    Evidencias

    O menu principal é o principal recurso de navegação do website e as subopções possuem tamanho de fonte 14px, o que está abaixo do recomendado:

    URLs a verificar

    Recomendações

    • Alterar o tamanho da fonte para que seja no mínimo, 16 píxeis.
    • O tamanho da fonte deve ser feito pelo atributo font-size diretamente no link a.

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

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

Lista de evidências recolhidas:

  • evidência: issue #34 Breadcrumbs não representam corretamente a localização do utilizador

    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 site da Câmara Municipal de Bragança, as breadcrumbs não representam corretamente a posição do utilizador na estrutura do site nem o percurso de navegação até à página em que se encontram.

    Image

    Figura – Página Legislação. O caminho de breadcrumbs (Transparência > Comunicação) que aparece na página está incompleto. Breadcrumbs destacada através de um retângulo de borda branca.

    Recomendações:
    Recomendamos reformular este componente para que apresente, de forma precisa, a página onde o utilizador se encontra e o trajeto desde a página inicial.

  • evidência: 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 site da Câmara Municipal de Bragança 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 do site do Município de Bragança na página de interior Regimento das Reuniões da Câmara Municipal.

    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 4.1 - Os documentos longos têm um índice no topo com hiperligações internas para o mesmo

etiqueta: NOK

Lista de evidências recolhidas:

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

etiqueta: NOK

Lista de evidências recolhidas:

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

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

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

    Embora a versão mobile seja tecnicamente responsiva, a adaptação do layout provoca cortes de informações. Por exemplo na página inicial a secção “Serviços mais frequentes” apresenta nas opções "Calculadora Ecológica, Espaços Verdes, Horários e Regulamentos e Despachos". (Figura 01)

    Image

    Figura 01 - Página inicial com problemas de cortes de informações

    Além disso, foram identificadas situações em que elementos relevantes são ocultados na versão mobile, afetando a navegação e o acesso à informação. Como o breadcrumb que desaparece dos ecrãs em dispositivos menores, e fica disponível apenas em dispositivos com dimensões maiores (Figura 2 e 3).

    Image

    Figura 02 - Breadcrumb desaparece nas versões para Android e iOS

    Image

    Figura 3 - Breadcrumb reaparece na versão para iPad Mini, Tablets e Desktop

    A ausência do breadcrumb pode causar desorientação, e ocultação deste tipo de elementos compromete a perceção e afetar a consistência da interface entre dispositivos.

    URLs a verificar

    Recomendação
    Recomendamos rever e corrigir espaçamento e margens responsivas entre conteúdos e textos das áreas clicáveis. Garantir que o breadcrumb (ou um mecanismo de navegação equivalente) permanece visível em dispositivos móveis, assegurando a orientação do utilizador e a consistência da navegação entre diferentes tamanhos de ecrã.

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

etiqueta: NOK

Lista de evidências recolhidas:

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

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

    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, está disponível um chatbot que é acionado apenas através da interação por hover. Ao passar o rato, surge a mensagem “Fale connosco – Precisa de ajuda?”. (Figura 01)

    Image

    Figura 01 - Chatbot ativo apenas com hover

    Há componentes das galerias de fotos das páginas de notícias, diponíveis apenas com hover. Por exemplo na página FEIRA DO LIVRO DE BRAGANÇA: A CULTURA NO CORAÇÃO DA CIDADE (Figura 2)

    Image

    Figura 2 - Setas interativas e legenda da galeria de imagens disponível com hover

    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.

    URLs a verificar

    Recomendação
    Garantir que os elementos interativos podem ser accionados através de outros tipos de interação como o teclado, toque e tecnologias de apoio. E que o chatbot pode ser acionado por estes diferentes métodos de interação com 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:

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

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

    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 há elementos interativos com área clicável que não cumprem a dimensão mínima exigida (44px de altura e largura). Por exemplo, na página “Caracterização” com os botões das redes sociais dimensão de 40px de largura e 40px de altura, não cumprindo as dimensões mínimas necessárias. (Figura 1)

    Image

    Figura 1 - Botões das redes sociais não cumprem com a área mínima recomendada.

    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 proporcional a esta área clicável e visível.

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:

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

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

    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) demonstra que na página das “Freguesias” o botão de ação principal “Voltar” não têm destaque suficiente face aos restantes botões da página. Os botões secundários devem estar menos destacados e com um estilo diferente. (Figura 01)

    Image

    Figura 01 - Botões de ação principal não possuem estilo único no website

    Além disso, observamos na página Checkin, que apesar do botão “Entrar” se destacar como ação principal, apresenta o mesmo estilo e cor de outros elementos da interface, como cartões, menu lateral, paginação e estados de hover.
    Ao definir e aplicar uma hierarquia visual consistente para os botões, reduz-se a probabilidade de ações secundárias serem confundidas com ações principais, contribuindo para uma navegação mais clara e uma melhor experiência do utilizador.

    URLs a verificar

    Recomendações
    Os botões de ação principal devem apresentar diferenciação visual clara em relação a elementos secundários e estruturais. Sugere‑se reforçar o peso visual (ex.: maior contraste, preenchimento, borda ou forma distinta) e utilizar cores diferenciadas e consistentes de ação principal, para garantir que o utilizador reconheça imediatamente a função principal.

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

etiqueta: NOK

Lista de evidências recolhidas:

  • evidência: issue #11 Elementos interativos devem aparentar ser clicáveis

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

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

    Evidências:

    • 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.
    • 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.

    A evidência (1) revela contraste inferior nos botões do menu secundário, em elementos interativos que devem aparentar ser clicáveis. (Figura 1)

    Image

    Figura 1 - Captura da página Comunicação do website de Bragança

    • A evidência (2) revela que a página inicial apresenta elementos interativos cujos estilos visuais não sugerem clicabilidade. Por exemplo os botões das redes sociais, textos da opção "Selecionar idioma" e da secção "Serviços mais frequentes". A única indicação de interação é a mudança do cursor ao passar o rato, o que não é suficiente para transmitir ao utilizador que se trata de elementos clicáveis.
    Image

    Figura 2 - Captura da página inicial de Bragança

    URLs a verificar

    Recomendações
    Rever o estilo dos elementos interativos para que seja mais percetível que são clicáveis. É necessário a revisão das cores dos vários estados dos elementos para garantir os valores mínimos de contraste em elementos interativos.

Checklist Transação

etiqueta: NOK

Nível de conformidade:

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

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

etiqueta: N/A

Lista de evidências recolhidas:

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:

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

etiqueta: NOK

Lista de evidências recolhidas:

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

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

    Evidências:
    Os campos “Tipo de Atendimento”, “Área de Atendimento” e “Data” da página Agendamentos estão demasiado largos para o tipo de informação que o utilizador precisa de inserir.

    Nos dois primeiros campos, a largura do campo de input é muito superior ao tamanho das opções apresentadas na lista suspensa, o que cria espaço vazio desnecessário. No caso do campo “Data”, considerando que o formato de preenchimento é dd/mm/aaaa (2 dígitos para o dia, 2 para o mês e 4 para o ano), a largura atual também não se justifica, pois excede claramente o espaço necessário para esse padrão de entrada.

    Image

    Figura – Formulário da página Agendamentos.

    URL a verificar:
    Página Agendamentos

    Recomendações:
    Recomendamos ajustar a largura dos campos para que corresponda ao tamanho real da informação a inserir.

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

etiqueta: N/A

Lista de evidências recolhidas:

  • evidência: issue #25 Não foram identificados formulários que utilizem revelação progressiva

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

    No site da Câmara Municipal de Bragança, não foram encontrados campos cujo conteúdo dependente seja ocultado ou revelado automaticamente com base na ativação de um campo chave. Assim, o requisito 2.2. da Checklist de Transação é avaliado como “Não aplicá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:

  • evidência: issue #24 O texto placeholder está a substituir o rótulo na interface gráfica

    etiqueta: R 2.3etiqueta: melhoriaetiqueta: chk transação

    Evidências:
    O campo de pesquisa geral no cabeçalho e o campo de pesquisa da página Pesquisa utilizam texto placeholder como substituto visual do rótulo. Embora os rótulos existam no código — “Pesquisar” — estão ocultos através das classes sr-only-label e hidden. Isto faz com que o utilizador dependa apenas do placeholder para perceber a função do campo, o que reduz a clareza e pode comprometer a acessibilidade.

    Image

    Figura 1 – Análise do campo de pesquisa, no cabeçalho do site, através do Google Inspector.

    Image

    Figura 2 – Análise do campo de pesquisa, na página Pesquisa, através do Google Inspector.

    URLs e componentes a verificar:

    • Campo de pesquisa localizado no cabeçalho do site;
    • Página Pesquisa – Campo de pesquisa;

    Recomendações:
    Recomendamos manter os rótulos sempre visíveis, tanto para quem usa leitores de ecrã como para quem interage visualmente com a interface, garantindo que a função de cada campo é clara em todos os contextos.

    Para mais informações, recomendamos consultar a página sobre boas práticas nos formulários da WebAIM.

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

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

Lista de evidências recolhidas:

  • evidência: issue #23 Atributo required aplicado incorretamente nos controlos do formulário

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

    Evidências:

    Verificámos que, no formulário da página Agendamentos, os campos “Tipo de Atendimento”, “Área de Atendimento” e “Data” não estão a indicar corretamente, de forma programática, que são de preenchimento obrigatório. Nos elementos <select> e <input> destes campos é utilizada a expressão required=”required”. Apesar de o leitor de ecrã reconhecer estes campos como obrigatórios, esta não é a forma semanticamente mais adequada de o declarar.

    Image

    Figura – Análise dos campos do formulário da página Agendamentos através do Google Inspector.

    URL a verificar:
    Página Agendamentos - Campos “Tipo de Atendimento”, “Área de Atendimento” e “Data”.

    Recomendações:
    Recomendamos utilizar o atributo required diretamente no elemento <select> quando o campo corresponde a uma lista suspensa e diretamente no elemento <input> no caso do campo “Data”.

    Recomendamos também aplicar o atributo required apenas no próprio controlo de formulário, evitando colocá-lo no elemento <label>, uma vez que o rótulo não deve transmitir obrigatoriedade de forma programática.

Requisito 3.1 - Em ações longas, o sistema deve indicar o que está a acontecer

etiqueta: N/A

Lista de evidências recolhidas:

Requisito 3.2 - Deve ser confirmado o sucesso da transação/envio de informação

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

Lista de evidências recolhidas:

  • evidência: issue #21 O Sucesso do envio/submissão da informação é confirmada

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

    Deve ser confirmado o sucesso da transação/envio de informação.
    ver requisito 3.2 na lista Transação

    Evidências:

    Na evidência (1) há um erro no campo "Motivo do contacto" mesmo preenchido aoresenta a mensagem "O campo 'Motivo do contacto' é obrigatório". (Figura 1)

    Imagem

    Figura 1 - Preenchimento de informações com erro no campo obrigatório

    URLs a verificar

    Recomendações
    Rever páginas dos formulários que apresentam problema em campos obrigatórios, mas apresentam mensagem de erro por não reconhecerem o preenchimento da informação pelos utilizadores.

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:

  • evidência: issue #19 As ações destrutivas nunca devem ser permanentes

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

    Evidências
    Não identificamos formulários que permitem o utilizador fazer ações destrutivas e por esse motivo, consideramos esse 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:

  • evidência: issue #18 As mensagens de erro são claramente identificadas junto aos campos de origem

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

    Evidências:

    Nota auditoria:

    • a relação programática entre campo de edição e mensagem de erro está estabelecida por via do atributo aria-describedby / id, apesar do aria-describedby referenciar um id que não existe - só existe quando a mensagem de erro é ativada. A regra ACT ARIA state or property has valid value menciona como regra geral que os valores dos atributos ARIA-* devem existir, mas estabele uma exceção: os ID de aria-describdby. Na interfac da CM Bragança as mensagens estão todas carregadas mas em estado hidden e só aparecem quando as mensagens disparam - isto corresponde ao caso descrito na exceção.

Outras violações

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

Lista de evidências recolhidas:

  • evidência: issue #117 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: outras violaçõesetiqueta: melhoria

    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-braganca.pt/servicos/investimento/visao-e-estrategia - 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.
  • evidência: issue #10 Outras violações - Calculadora ecológica com problemas em tooltips informativas

    etiqueta: outras violaçõesetiqueta: melhoria

    Evidência:

    A Calculadora ecológica do website, utiliza um iframe externo com problemas nas tooltips informativas, as quais são ativas apenas com o rato e torna o conteúdo inacessível para leitores de ecrã e dispositivos táteis, pelo que necessita de revisão.

    A evidência (1) revela que há uma “Calculadora ecológica” com tooltips informativas, que são acionadas apenas com a passagem do rato (hover) o que dificulta a compreensão em caso de dúvida para o utilizador. Apesar de ser um iframe de uma página externa, recomendamos rever o conteúdo disponível pois ele está inacessível por leitores de ecrã e também na interação por toque em dispositivos móveis. (Figura 1)

    Calculadora ecológica com tooltips ativas apenas com o rato

    Figura 1 - Calculadora ecológica incorporada no website possui problemas de acessibilidade

    URLs a verificar

    Recomendação
    Rever a calculadora para substituir tooltips dependentes de hover por elementos sempre acessíveis ou acionáveis por toque e teclado, garantindo total compatibilidade com leitores de ecrã.

  • evidência: issue #9 Outras violações - Componente de checkbox apresentam quebra de layout

    etiqueta: outras violaçõesetiqueta: melhoria

    Evidências
    Foi identificado um problema visual no componente de checkbox durante o processo de submissão do formulário. Embora a checkbox seja marcada corretamente ao nível funcional (ou seja, o estado "checked" é aplicado com sucesso), verifica-se uma inconsistência na apresentação visual. (Figura 1)

    Image

    Figura 1 - Quebra de layout no preenchimento da checkbox

    Concretamente, quando a checkbox é selecionada, o ícone de confirmação (check) apresenta um desalinhamento dentro da caixa, não estando centrado como esperado. Esse comportamento resulta numa quebra de layout, comprometendo a consistência visual da interface. Este tipo de problema pode afetar a perceção de qualidade da aplicação por parte dos utilizadores, uma vez que o componente aparenta estar renderizado de forma incorreta, mesmo estando funcionalmente correto.

    URLs a verificar

    Recomendações

    Recomenda-se a revisão dos estilos associados à checkbox, nomeadamente garantindo que o ícone de check está devidamente centrado tanto vertical como horizontalmente dentro do seu contêiner, assegurando assim uma apresentação consistente e alinhada com as boas práticas.

  • evidência: issue #7 Outras violações- Há páginas sem foco visível na navegação por teclado e leitor de ecrã

    etiqueta: outras violaçõesetiqueta: melhoria

    Evidências
    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)

    Image

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

    Image

    Figura 2 - Inconsistências: Há páginas que o foco está visível corretamente, por exemplo na página Notícias

    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

Significado das etiquetas utilizadas