Relatório Avaliação da Candidatura da Comunidade Intermunicipal da Região de Aveiro (sítio Web institucional)

Introdução

O website https://www.regiaodeaveiro.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: OK
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 aspetos44.4% (12/27)etiqueta: Não passa
Conteúdo52.9% (9/17)etiqueta: Não passa
Transação80.0% (8/10)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: OK

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: 44.4% (12/27)
    • Requisitos avaliados: 27 (27 aplicáveis)
    • Requisitos OK: 12
    • Requisitos NOK: 15

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 #95 Não é possível abrir as subopções do menu com o comando VO + Espaço

    etiqueta: R 1.2etiqueta: NOKetiqueta: chk 10 web

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

    Verifica-se que, em alguns menus, não é possível abrir as subopções utilizando o comando VO + Espaço. Este comando é nativo do leitor de ecrã Voice Over e pode gerar dúvidas quanto ao funcionamento do menu quando este não funciona:

    Image

    As subopções do menu principal não são exibidas quando utilizado o comando VO + Espaço no navegador Safari

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

    etiqueta: R 1.2etiqueta: melhoriaetiqueta: chk 10 web

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

    Descrição do problema

    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. Tal acontece porque a propriedade responsável por definir o estilo geral do contorno do foco se encontra com transparência, e os elementos no estado :focus não possuem um estilo definido para essa propriedade. Para além disso, as opções do menu quando estão em foco estão com um estilo que torna a sua leitura ilegível.

    Image

    Não é visível qual botão de subopção do menu está em foco

    Sugestão de correção
    • Definir um estilo visível para o contorno dos elementos interativos, utilizando à propriedade outline em CSS.
    • Outra alternativa, é manter o comportamento nativo dos navegadores, procedendo à remoção dos atributos de contorno actualmente definidos em CSS.

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:

  • issue #107 Associação explicita entre campo de edição e etiqueta

    etiqueta: NOKetiqueta: R 4.1etiqueta: chk 10 web
    Notas gerais
    • ao contrário da espetativa inicial de auditoria, não se observou consistência na forma de codificar os diferentes tipos de campos de edição em alguns websites: há campos do mesmo tipo que violam o requisito 4.1 e outros não
    • campos do tipo listbox estão, em alguns websites, a violar o requisito 4.1.
    • formulários PDF violam o requisito 4.1 e excluem cidadãos do seu preencimento. Deve ser disponibilizada uma versão de preenchimento acessível (p.e. em HTML). Isto afeta grande parte dos 20 websites analisados.

    Evidências:

    Nota de auditoria

    • CORRIGIDO. a evidência (1) revela que o campo do tipo "listbox", neste form com a etiqueta "Motivo de Contacto", não satisfaz o requisito uma vez que não está estabelecida a relação entre o campo e a etiqueta.
    • A evidência (2) revela não satisfação do requisito (ao focar o campo, o leitor de ecrã não revela qualquer etiqueta). Os formulários disponibilizados em PDF deverão ser substituídos por formulários em HTML ou com uma versão HTML que sirva de equivalente alternativo aos formulários disponibilizados em PDF.
    • Verificou-se que a evidência (2) revela que há campos (p.e. perguntas com checkboxes e radio buttons) que não são acessíveis via teclado.
    Formulário em PDF, impossíveis de serem acedidos por leitor de ecrã

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:

  • issue #106 Campos obrigatórios percetíveis com leitor de ecrã

    etiqueta: NOKetiqueta: R 4.2etiqueta: chk 10 web
    Nota geral
    • mensagem geral que informa significado do símbolo "*" não existe em alguns websites e, noutros, embora exista, surge escondido dos leitores de ecrã. Todos devem ter e deve ficar visível a todas as tecnologias, incluíndo leitores de ecrã.
    • a generalidades dos websites apresenta formulários em PDF que violam o requisito 4.2 e que excluem cidadãos com necessidades espeicias do seu preenchimento.

    Evidências:

    Nota de auditoria

    • na evidênca (1) não faz sentido esconder a mensagem global "Deverá preencher todos os campos assinalados com *(obrigatório)." das tecnologias de apoio. Usa-se aira-hidden="true". Deve ser removido.
    • Na evdência (2) não foi localizada quaisquer indicações para a obrigatoriedade de preenchimento dos campos. Percebeu-se também que existem manuais de ajuda ao preenchimento deste formulário.

Requisito 4.3 - É possível localizar e ler as mensagens de erro usando 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: NOKetiqueta: R 5.1etiqueta: chk 10 web
    Notas gerais
    • 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.
    • Há imagens informativas que não possuem um texto alternativo.
    • 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.

    Evidências:

    Nota de auditoria
    • Nas evidências (1 e 2) localizamos imagens que possuem textos alternativos incorretos. Na página de “Notícias”, por exemplo, todas as notícias possuem cards imagens com descrições incorretas e que causam ruídos de informação para utilizadores com leitores de ecrã. É necessário rever imagens que podem ser consideradas imagens decorativas e o atributo alt deve ser vazio (alt=""). No entanto, ao aceder à notícia completa, a imagem deve dispor de uma descrição apropriada.
    Image
    • Na evidência (3) há um carrossel de imagens que possuem textos alternativos incorretos e que não descrevem fielmente o propósito das respetivas imagens.

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: NOKetiqueta: R 5.3etiqueta: chk 10 web
    Notas gerais
    • 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.
    • 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
    • É 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.

    Evidências:

    Nota de auditoria

    • A evidência (1) demonstra a presença de imagens que funcionam como links na secção class="linksHomeContainer", mas que utilizam textos alternativos incorretos ou pouco descritivos. Um exemplo é o logótipo “Região de Aveiro Digital – Central de Compras”, que apresenta o texto alternativo alt="botao_rad_central_compras_02", o qual não descreve o conteúdo nem o destino do link. Esta prática compromete a compreensão para utilizadores de leitores de ecrã, afetando a perceção adequada da função e do propósito dos links.
    Image

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:

  • issue #68 Problemas de contraste para texto normal

    etiqueta: NOKetiqueta: R 6.1etiqueta: chk 10 web
    Notas gerais
    • Contraste inferior para elementos textuais, elementos da interface e objetos gráficos.
    • 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

    Evidências:

    Nota de auditoria

    • a evidência (1) revela que o * dos campos obrigatórios com cor #FF6C79 não cumpre o requisito pois possui rácio de contraste inferior em relação ao plano de fundo (#FFFFFF)
    Image
    • a evidência (2) demonstra problemas de contraste no rodapé do website, nas combinações de cores #236EAC(cor do primeiro plano) e #0F4260 (cor de plano de fundo). Sendo assim, não passa na avaliação de contraste.
    Image

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 #89 Existem elementos que estão a ser lidos apenas pelos leitores de ecrã

    etiqueta: NOKetiqueta: R 8.2etiqueta: chk 10 web

    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

    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 leitura duplicada das etiquetas:

    Image

    _Campo de pesquisa estruturado com o botão do tipo input type="image" e com uma label visível aos leitores de ecrã (alteramos manualmente para fins de teste)

    Image

    Leitor de ecrã anuncia a label que está visível apenas para tecnologias de apoio

    Sugestão de correção
    • 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:

  • issue #112 Existem acordeões construídos de forma inapropriada

    etiqueta: NOKetiqueta: R 8.3etiqueta: chk 10 web

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

    Por exemplo, na página Grupo de Ação Costeira 2021-2027 existem acordeões que estão sendo estruturados como divs e recebem a semântica através do role="button":

    Image

    Acordeão estruturado com o role="button" ao invés de ser estruturado com a tag button do HTML

    Para além disso, o acordeão tem como função compactar o conteúdo da página. Neste caso específico, está a ser utilizado como substituto de um índice, uma vez que organiza e condensa a informação apresentada. Quando o acordeão é utilizado com este propósito, é necessário que os seus títulos estejam corretamente estruturados como cabeçalhos, o que não se verifica neste caso:

    Image

    Títulos dos acordeões estruturado como parágrafos ao invés de serem títulos

    Sugestão de correção
    • Estruturar o acordeão semanticamente como um botão, utilizando a tag button do HTML.
    • Os títulos devem ser estruturados como cabeçalhos. Para isso é necessário garantirem a hierarquia entre os cabeçalhos na página.
    • A tag do cabeçalho deve conter a tag button e não o contrário, pois assim não se perde a semântica do cabeçalho:
    Image

    Tag h3 contém a tag button

    • É 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 #88 Existem elementos interativos (links, botões) estruturados com a tag div

    etiqueta: NOKetiqueta: R 8.3etiqueta: chk 10 web

    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

    Ao desativar o CSS, é possível identificar links e botões que não possuem semântica adequada, uma vez que estão a ser estruturados com divs. Esta prática pode causar problemas de navegação utilizando o teclado e com leitores de ecrã, pois estes elementos não recebem foco via teclado nem são corretamente anunciados pelos leitores de ecrã.

    Por exemplo, no website da Comunidade Intermunicipal da Região de Aveiro foram identificados modais cujas opções de voltar, avançar e fechar se encontram estruturadas como div:

    Image

    Opções de avançar, voltar e fechar modal estão estruturadas como divs

    Sugestão de correção
    • É importante garantir que todos os elementos interativos do website — como botões, links, controlos de carrosséis, modais, galerias de imagens e outros elementos acionáveis — sejam construídos utilizando elementos nativos do HTML.
    • Deve ser dada especial atenção aos elementos que atualmente só podem ser acionados com o rato, pois na maioria dos casos isto indica uma ausência de semântica adequada no código. A verificação deve focar-se principalmente nos controlos de carrosséis, modais, galerias de imagens e outros elementos interativos críticos, garantindo que todos possam ser utilizados sem dependência exclusiva do ponteiro do rato.

  • issue #86 O chatbot e o componente de contactos/fale connosco não estão estruturados de forma apropriada

    etiqueta: NOKetiqueta: R 8.3etiqueta: chk 10 web
    Descrição do problema

    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, no website da Comunidade Intermunicipal da Região de Aveiro, onde é possível identificar a opção de contactos apresentado no rodapé que está construído com divs. Isso faz com que o componente não seja acessível através do teclado nem por leitores de ecrã:

    Image

    Componente fixo está construído como div no website Comunidade Intermunicipal da Região de Aveiro

    Sugestão de correção
    • Devem rever os componentes flutuantes no rodapé, como contactos/fale connosco.
    • Devem garantir que a opção de contactos 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 #69 O leitor de ecrã identifica mais opções do que é apresentado visualmente no carrossel

    etiqueta: NOKetiqueta: R 8.3etiqueta: chk 10 web

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

    O carrossel existente na secção “Notícias” da página inicial da Região de Aveiro apresenta mais elementos aos leitores de ecrã do que aqueles que aparecem visualmente, de cada vez.

    Image

    Recomendamos que os itens 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.

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

    etiqueta: NOKetiqueta: R 8.3etiqueta: chk 10 web

    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:

    O carrossel presente na página inicial da Região de Aveiro (secção notícias) não permite pausar a passagem dos elementos.

    Image

    Para além disso, não informam quantos itens fazem parte do carrossel,
    Acresce ainda que os botões para avanço e recuo nos elementos dos carrosséis não estão etiquetados e foram estruturados com uma semântica incorreta não nativa para estes controlos.

    Image

    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, pode incluir um botão que permita pausar a passagem dos itens.
    Recomendamos ainda a correta estruturação dos botões (button ao invés de div), bem como a colocação de nomes acessíveis nos mesmos
    Para mais informações é possível consultar os artigos Carousel Structure e Carousel (Slide Show or Image Rotator) Pattern do W3C.

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

    etiqueta: melhoriaetiqueta: R 8.3etiqueta: chk 10 web
    Descrição do problema

    Verifica-se que existem conteúdos que não estão estruturados como listas. Por exemplo, o glossário da Comunidade Intermunicipal da Região de Aveiro não está estruturado como uma lista de definição:

    Image
    Sugestão de correção

Requisito 9.1 - Quando a caixa de diálogo é aberta, o foco (cursor do Browser) move-se para um elemento dentro da caixa de diálogo

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #64 O foco não é direcionado para dentro da modal

    etiqueta: NOKetiqueta: R 9.1etiqueta: chk 10 web

    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

    Descrição do Problema
    Quando uma modal é aberta, o foco do teclado deve ser automaticamente direcionado para dentro dela. Isto garante que os utilizadores que navegam com o teclado, incluindo aqueles que recorrem a tecnologias de apoio, possam interagir facilmente com o conteúdo apresentado e percebam que uma nova interação está disponível.
    Na página Galerias de Imagens, quando o utilizador seleciona uma das imagens colocadas logo abaixo do título de nível 1(“Galeria de Imagens”), é aberta uma janela modal. No entanto, o foco não é automaticamente direcionado para o seu conteúdo.

    Sugestão de Correção
    Recomendamos ajustar o foco para que, ao abrir a modal, o cursor seja automaticamente direcionado para o primeiro elemento interativo dentro da modal.

    Exemplo de Conteúdos que Necessitam de Correções

    Image

    Figura - Teste da modal da página Galerias de Imagens através do leitor de ecrã NVDA. Quando a modal é aberta, o foco não é direcionado para o conteúdo que está dentro da modal.

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #63 O foco não está limitado à modal

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

    Descrição do Problema

    Manter o foco do teclado dentro da caixa de diálogo garante que os utilizadores possam interagir com o seu conteúdo sem distrações de outros elementos na página. Este controlo do foco facilita a navegação, ajudando os utilizadores a compreenderem a sua posição na interface.

    Na página Galerias de Imagens, quando o utilizador seleciona uma das imagens da galeria (localizadas logo abaixo do título de nível 1), é aberta uma janela modal. No entanto, mesmo quando esta modal está aberta, o leitor de ecrã continua a percorrer o restante conteúdo da página que se encontra por baixo da janela de modal.

    Sugestão de Correção

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

    Exemplo de Conteúdos que Necessitam de Correções

    Image

    Figura - Teste com o leitor de ecrã NVDA. Na modal da página Galerias de Imagens, quando a modal está aberta, continua a ser possível percorrer com o leitor de ecrã o restante conteúdo da página que está por baixo da modal.

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #60 O elemento para fechar a modal não possui um texto alternativo

    etiqueta: NOKetiqueta: R 9.3etiqueta: chk 10 web

    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

    Descrição do Problema
    As modais devem apresentar um botão de fechar claramente visível e acessível através do teclado. Além disso, podem permitir que os utilizadores as fechem pressionando a tecla 'Esc'. Essas opções garantem que utilizadores de teclado e leitores de ecrã consigam interagir com a modal de forma eficaz.
    Na página Galerias de Imagens, o elemento utilizado para fechar a janela modal não possui texto alternativo.

    Sugestão de Correção
    Recomendamos rever este elemento de forma a assegurar que tem um texto alternativo associado que descreva de forma clara e inequívoca a sua função – por exemplo, “Fechar a janela de modal”.

    Exemplo de Conteúdos que Necessitam de Correções

    Image

    Figura - Teste da modal da página Galerias de Imagens através do leitor de ecrã NVDA. O elemento para fechar a modal não tem um texto alternativo associado. A leitura que é feita pelo leitor de ecrã deste elemento está destacada através de um retângulo de borda preta.

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #58 O foco é perdido quando a janela modal é fechada

    etiqueta: NOKetiqueta: R 9.4etiqueta: chk 10 web

    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

    Descrição do Problema
    Garantir que o foco retorne ao botão que acionou a modal é uma prática que beneficia especialmente pessoas que utilizam navegação por teclado ou leitores de ecrã, ajudando-as a manter-se orientadas dentro da interface.
    Ao fechar uma modal, se o foco é perdido ou deslocado para um local inesperado, os utilizadores precisarão percorrer novamente a interface até chegar no local desejado para continuar a interação desejada.

    Na página Galerias de Imagens, quando o utilizador seleciona uma das imagens da galeria (localizadas logo abaixo do título de nível 1), é aberta uma janela modal. Quando se fecha esta janela de modal, o foco não retorna para o elemento que a acionou.

    Sugestão de Correção
    Recomendamos reverem as modais de forma a garantir que, quando a janela de modal é fechada, o foco retorna ao elemento interativo que a acionou.

    Exemplo de Conteúdos que Necessitam de Correções

    Image

    Figura - Teste com o leitor de ecrã NVDA na modal da página Galerias de Imagens. Ao fechar a janela de modal, o foco do leitor perde-se.

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:

  • issue #70 Preservação do texto em PDF

    etiqueta: NOKetiqueta: R 10.1etiqueta: chk 10 web

    A análise do critério cingiu-se a apenas 2 tipos de documentos:

    • planos de atividades, prestação de contas, com textos e números
    • cartas, declarações, avisos, de caráter público, com mensagens em texto

    O objetivo do requisito é analisar como é que a entidade faz chegar ao cidadão as suas mensagens escritas. Não tem por objetivo analisar Mapas, plantas ou outro tipo de imagens.

    Evidências:

    Nota de auditoria

    • (1) subvenções - só texto disposto em tabela e colocado em landscape. É selecionável, mas o texto que está sincronizado não está correto. Qualquer palavra que se selecione resulta em "y y y " (!?)
    • (2) ata em texto que se apresenta como imagem de texto

    Nota: não se conseguiu usar o seletor de páginas da pesquisa para passar da 1ª para a 2ª página de resultados.

Checklist Conteúdo

etiqueta: NOK

Nível de conformidade:

  • Checklist Conteúdo: 52.9% (9/17)
    • Requisitos avaliados: 17 (17 aplicáveis)
    • Requisitos OK: 9
    • Requisitos NOK: 8

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:

  • issue #40 A informação sobre contactos no rodapé possui tamanho inferior a 16px

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

    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

    Descrição do problema

    O contacto principal da Comunidade Intermunicipal da Região de Aveiro é uma informação primária e encontra-se estruturada como conteúdo secundário, com um tamanho de fonte de 14px:

    Informação de contactos com tamanho de fonte abaixo de 14 pixels

    Sugestão de melhoria
    • Rever a informação apresentada nos websites, de forma a garantir que o conteúdo considerado como principal, como o o contacto com o município, utilize um tamanho mínimo de letra de 16 pixels.

Requisito 2.2 - A informação secundária (datas, autores) utiliza, no mínimo, um tamanho de letra de 10 pontos

etiqueta: NOK

Lista de evidências recolhidas:

Requisito 3.1 - Nenhum nível de navegação tem mais de 9 opções

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #35 Número excessivo de opções no menu de rodapé

    etiqueta: NOKetiqueta: chk conteúdoetiqueta: R 3.1

    Nenhum nível de navegação tem mais de 9 opções.
    – ver requisito 3.1 na lista Conteúdo

    Descrição do Problema
    As boas práticas recomendam que nenhum nível do menu deve ter mais do que 9 opções. A navegação deve ser equilibrada e não deve exigir muito esforço cognitivo por parte dos utilizadores, que normalmente retêm entre 5 a 9 opções na memória de curto prazo.

    No rodapé, abaixo do cabeçalho de nível 2 “Municípios”, existem 11 subopções, o que significa que está acima do número de opções recomendado.

    Sugestão de Correção
    Deve ser feita uma revisão da arquitetura de informação do rodapé de forma a garantir que não ultrapasse 9 opções em cada nível do mesmo.

    Exemplo de Conteúdos que Necessitam de Correções

    • No rodapé, as subopções do cabeçalho de nível 2 “Municípios”
    Image

    Figura - Análise das subopções do cabeçalho de nível 2 "Municípios", no rodapé do site, através do Google Inspector. Estas subopções encontram-se destacadas no código através de um retângulo de borda preta.

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 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: R 5.1etiqueta: chk conteúdo

    Notas gerais

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

    Evidências:

    Nota de auditoria
    • A evidência (1) revela na página inicial o mapa interativo, é acionado apenas com a passagem do rato (hover) nas regiões que são clicáveis e direcionam para páginas dos municípios. No entanto, o mapa é inacessível com leitores de ecrã e o hover não é perceptível para dispositivos móveis (notas do Requisito 5.2 - 10 Aspetos)
    Mapa interativo com interação apenas com hover

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

    Notas Gerais

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

    Evidências:

    Nota de auditoria

    • a evidência (1) revela que o botão do carrossel com 42x42px, não cumpre a dimensão mínima recomendada.
    Image

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: R 5.3etiqueta: chk conteúdo

    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

    Notas gerais

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

    Evidências:

    Nota de auditoria

    • a evidência (1) revela que na página “Comunicação” não é possível distinguir o qual é o botão de ação principal da página.
    Image

    Recomendações

    Recomendamos remover a barra do botão “Voltar” e aplicar um estilo de botão principal, e tornar as opções “Notícias”, “Eventos”, “Notas de Imprensa”, “Boletim Informativo”, “Galerias de Imagens” e “Galerias de Videos” como botões secundários.

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

    Notas Gerais

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

    Evidências:

    Nota de auditoria

    • a evidência (1) revela que há elementos interativos no website com pouco contraste. Por exemplo, os botões dos carrosséis suas combinações de cores tem uma taxa de contraste (2,1:1) inferior ao recomendado.
    Image

Checklist Transação

etiqueta: NOK

Nível de conformidade:

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

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 Formulários grandes com organização por páginas (passos) - rever no final

    etiqueta: R 1.2etiqueta: chk transação

    Verifica-se que os formulários do website possuem tamanho menor que 2 ecrãs. Como por exemplo o formulário de Sugestões / Reclamações / Elogios:

    Atenção: embora o tamanho do formulário seja conforme recomendado ele está sendo apresentado de forma duplicada. Devem remover um dos formulários.

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 Formulários grandes revelam mecanismo de navegação por passos

    etiqueta: R 1.3etiqueta: N/Aetiqueta: chk transação

    Não foi identificado no website formulários segmentado por etapas. Por esse motivo, consideramos o critério como "Não aplicável".

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

etiqueta: N/A

Lista de evidências recolhidas:

  • issue #25 Uso de revelação progressiva em vez de campos (opções) inativas

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

    Não foi identificado no website formulários que utilizem uma revelação progressiva dos campos. Por esse motivo, consideramos o critério como "Não aplicável".

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

etiqueta: NOK

Lista de evidências recolhidas:

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

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

    Verifica-se que no formulário de Sugestões / Reclamações / Elogios é possível localizar a mensagem de sucesso de envio do formulário:

    Image

    No entanto, assim que a mensagem de confirmação é apresentada, esta não é anunciada automaticamente pelo leitor de ecrã. Como consequência, o utilizador tem de a procurar manualmente e, durante essa navegação, verifica-se que o foco do leitor de ecrã é alterado: em vez de permanecer no botão “Submeter”, é reposicionado no cabeçalho:

    Image

    Leitor de ecrã não anuncia automaticamente a mensagem de confirmação de envio mesmo já sendo apresentado no ecrã

    Image

    O primeiro foco do leitor de ecrã é no cabeçalho h1 da página

    Recomendamso que a mensagem de erro seja anunciada automaticamente pelo leitor de ecrã.

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: N/Aetiqueta: chk transaçãoetiqueta: 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: OK (no entanto contém 1 melhoria que se recomenda efetuar)

Lista de evidências recolhidas:

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

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

    Verifica-se que no formulário de Sugestões / Reclamações / Elogios 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:

    Image

Significado das etiquetas utilizadas