O website https://www.cm-alcobaca.pt/ etiqueta: passa nos requisitos mínimos do Selo de Usabilidade e Acessibilidade.
| Tipo de avaliação | Estado |
|---|---|
| Avaliação Automática | etiqueta: OK |
| Avaliação Manual | etiqueta: OK |
Das avaliações manuais efetuadas obtiveram-se os resultados que se sintetizam na tabela seguinte.
| Checklist | Conformidade alcançada | Resultado |
|---|---|---|
| 10 aspetos | 81.8% (18/22) | etiqueta: Passa |
| Conteúdo | 87.5% (14/16) | etiqueta: Passa |
| Transação | 88.9% (8/9) | 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.
etiqueta: OK
De acordo com o artigo 8º do DL n.º 83/2018, todos os sítios web e todas as aplicações móveis têm de ostentar uma Declaração de Acessibilidade. A Declaração é o documento na qual a organização evidencia o trabalho levado a efeito para tornar os seus conteúdos e serviços digitais mais acessíveis, disponibilizando ainda contactos para ajuda adicional.
Lista de evidências recolhidas:
evidência: issue #83 Declaração de Acessibilidade - As avaliações das checklists (S/N/NA) não estão alinhadas com as avaliações da auditoria
evidência: issue #79 Declaração de Acessibilidade - Critérios com avaliação "Sim" sem evidências nas checklists de 10 aspectos, Conteúdo e Transação
Existem critérios avaliados como SIM sem evidências. Devem apresentar sempre alguma evidência em imagem e notas de que estão a cumprir ou a chumbar o critério antes de receberem o Selo.
- 4.1 Ao clicar com o rato na etiqueta, o cursor surge no respetivo campo de edição
E mais outros critérios:
Pedimos que revejam esses pontos, assim como a avaliação (SIM, NAO, N/A) que atribuímos aos critérios, antes de voltarem a submeter as 3 checklists.
evidência: issue #78 Declaração de Acessibilidade - Rever as evidências da checklist de Transação
Considerando que a checklist de Transação passa a ser necessária para a candidatura ao Selo Prata, devem rever as evidências da checklist de acordo com este relatório.
evidência: issue #64 Declaração de acessibilidade - Atualizar os ficheiros das checklists
Após as correções, é necessário incluir as respectivas evidências em cada checklist enviada junto ao relatório (10 aspectos e de Conteúdo) e atualizar a Declaração de Acessibilidade com os respectivos ficheiros.
evidência: issue #63 Declaração de acessibilidade - Garantir formato machine-readable
Ao submeter novamente o ficheiro da Declaração ao Gerador (https://www.acessibilidade.gov.pt/gerador/), este não reconhece a informação, nem preenche os campos automaticamente, o que é sinal de que o formato da Declaração está corrompido.
Quando se termina o preenchimento da Declaração no Gerador, deve-se descarregar o código HTML e colá-lo numa página do site. Dessa forma, garante-se que a informação da Declaração é machine-readable.
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:
evidência: issue #82 Avaliação automática - O link "Saltar para o conteúdo principal" tem um tabindex superior a 0
Definir o atributo tabindex com um valor maior que zero pode criar uma ordem de navegação imprevisível, o que pode desorientar os utilizadores e dar a sensação de que alguns elementos estão a ser ignorados.
<a id="goToContent" tabindex="1" aria-label="" href="#mainContent" target="_self">Saltar para o conteúdo principal da página</a>
Este problema foi detectado na avaliação automática com Rocket Validator.
Para corrigir este problema, recomenda-se alterar o valor para tabindex="0", permitindo que o elemento siga a ordem natural do documento.
Em alternativa, pode remover o tabindex="0" do link e o tabindex="-1" do main e reorganizar o HTML para garantir a sequência correta dos elementos.
evidência: issue #81 Avaliação automática - A modal dos cookies com atributo role="dialog" não tem nome acessível
Elementos com o atributo role="dialog" ou role="alertdialog" devem ter um nome acessível para que utilizadores de leitores de ecrã possam compreender o propósito do diálogo quando este é aberto.
A dialog dos cookies não tem um nome acessível:
<div class="modal fade show" aria-modal="true" role="dialog" tabindex="-1" style="display: block;">
Este problema foi identificado na avaliação automática do Rocket Validator.
Para corrigir isto, é adicionar um atributo aria-label com um nome descritivo, ou aria-labelledby para referenciar um título visível ou um elemento de texto dentro da diolog (ex: Visão geral da privacidade).
etiqueta: OK
A avaliação manual é feita por inspeção perícial dos diversos requisitos constantes da:
Sempre que os auditores localizam uma falha grave de um requisito de acessibilidade que, embora não faça parte do esquema de requisitos do Selo, se enquadre no âmbito das violações das WCAG 2.1 'AA' do W3C, tal referência é anotada em "Outras violações" do presente capítulo. Apesar destas violações não se apresentarem com carácter vinculativo no esquema de requisitos do Selo, recomenda-se que as mesmas sejam corrigidas.
etiqueta: NOK
Nível de conformidade:
etiqueta: NOK
Lista de evidências recolhidas:
evidência: issue #9 Outras melhorias - O componente de paginação não está estruturado como <nav> e não tem aria-label
O elemento de paginação em páginas como Marcas Identitárias ou Avisos é anunciado pelo leitor de ecrã apenas como “lista de 7 opções”, sendo também indicada a posição de cada link dentro da lista.
Figura 1 - Paginação na página Marcas Identitárias.
No entanto, não é fornecido pelo leitor de ecrã qualquer contexto adicional que identifique este componente como um elemento de navegação, o que dificulta a compreensão da sua finalidade.
Rever o elemento de página em todas as páginas:
Estruturar o elemento de paginação como <nav>.
Adicionar um aria-label para distinguir esse <nav> do <nav> principal. Por exemplo: <nav aria-label="Paginação"
evidência: issue #4 Subopções do menu de mobile não estão estruturadas como listas
<ul> e <li>.<div>. O leitor de ecrã não comunica que é uma lista, nem quantos elementos existem.Figura 1 - Inspect das subopções do menu em mobile revela que as opções estão apenas estruturadas como divs.
Figura 2 - Inspect do botão "Município" do menu de mobile revela que o texto está dentro do botão.
<ul><li>.etiqueta: N/A
Lista de evidências recolhidas:
evidência: issue #10 R 3.1 - Não existem tabelas no site, por isso não é aplicável a estrutura de cabeçalhos com <th>
No ficheiro Excel das evidências, consideram que a página Boletim contém tabelas, mas apresenta apenas uma lista, não uma estrutura de <table> nem conteúdo que necessite dessa estrutura.
Colocar como "Não aplicável" no Excel dos 10 aspectos funcionais da candidatura, uma vez que parece não existem tabelas no site.
etiqueta: N/A
Lista de evidências recolhidas:
evidência: issue #11 R 3.2 - Não existem tabelas no site, por isso não é aplicável a legenda estar marcado com o <caption>
No ficheiro Excel das evidências, consideram que a página Boletim contém tabelas, mas apresenta apenas uma lista, não uma estrutura de <table> nem conteúdo que necessite dessa estrutura.
Colocar como "Não aplicável" no Excel dos 10 aspectos funcionais da candidatura, uma vez que parece não existem tabelas no site.
etiqueta: NOK
Lista de evidências recolhidas:
evidência: issue #14 Campos de input sem etiqueta (label) e estruturados como outros elementos
Existem campos de input que não estão estruturados como tal e sem label associada:
aria-label do input, não do <span> visualmente escondido.Figura 1 - HTML do campo da pesquisa
aria-label do input, não do span visualmente escondido.Figura 2 - HTML do campo do email para receber newsletter
<div> e o input noutra <div>, quebrando a ligação adjacente do HTML nativo.Figura 3 - HTML da checkbox dos termos e condições
<label>) associado. Não é possível interagir com esse campo através do teclado e leitor de ecrã.Figura 4 - HTML do campo de data picker da página inicial
Figura 5 - HTML do campo da categoria da página inicial
Na página Eventos, os mesmos problemas são encontrados no campo da categoria e intervalo de datas.
Figura 6 - HTML do campo da categoria da página Eventos
Figura 7 - HTML do campo de intervalo de datas da página Eventos
Devem garantir que todos os campos de edição, dropdowns, pesquisa, date pickers, são estruturados como <input> e com uma <label>. Oforda <label> deve ter o mesmo valor que o id do <input>, para que o leitor de ecrã consiga comunicar a informação da label do campo quando foca no componente, assim como o cursor surgir no respectivo campo de edição quando se clica na etiqueta.
No caso do campo de categoria devem estruturar como uma multi-select combobox.
No caso do campo de intervalo de datas devem estruturar como um date picker combobox, com uma label associada. Podem seguir o exemplo do elemento Date Picker Combobox Example da W3C. como referência.
No caso da checkbox, devem garantir que o input está associado à label. Podem consultar a página Labeling Controls - Checkbox da W3C como referência.
A label de todos os campos mencionados deve ficar visível e não ser escondida do leitor de ecrã através de <span> ou ser atribuída através de um aria-label. A label estar constantemente visível permite relembrar cognitivamente o que as pessoas estão a inserir nos campos.
Não é necessário a label estar fora do campo, quando o campo ainda não tem input inserido, mas quando o input é inserido, a
Não devem utilizar o placeholder do campo como substituto da label.
etiqueta: N/A
Lista de evidências recolhidas:
evidência: issue #35 R 5.2 - 10 Aspetos
O gráfico é acompanhado de uma descrição longa.
– ver requisito 5.2 na lista 10 aspetos
etiqueta: N/A
Lista de evidências recolhidas:
evidência: issue #38 R 7.1 - 10 Aspetos
Deve ser possível ativar os botões de controlo do leitor quer com o rato quer com o teclado.
– ver requisito 7.1 na lista 10 aspetos
etiqueta: N/A
Lista de evidências recolhidas:
evidência: issue #39 R 7.2 - 10 Aspetos
O vídeo ou áudio deve conter preferencialmente legendas fechadas sincronizadas.
– ver requisito 7.2 na lista 10 aspetos
etiqueta: NOK
Lista de evidências recolhidas:
evidência: issue #17 Quando se retira a CSS, a informação relevante não permanece visível
Quando se retira a CSS, não aparece visível nenhuma informação sobre o botão das redes sociais, incluindo o seu texto alternativo.
Figura 1 - Botões das redes sociais do topo da página sem CSS
Figura 2 - Botões das redes sociais abaixo do campo da pesquisa sem CSS
Acontece que o HTML dessas imagens-link estão mal estruturadas, estando uma <div> dentro de um link (<a>).
Figura 3 - HTML das imagens - links das redes sociais
Remover a <div>, um elemento block, dentro do link (<a>), um elemento inline. Seguir a construção nativa HTML de um link que contém uma imagem.
Além disso, garantir que os estilos CSS não estão aplicados a uma <div>, mas à imagem.
etiqueta: NOK
Lista de evidências recolhidas:
evidência: issue #20 Existem PDFs onde não é possível extrair o conteúdo textual para formato TXT
Foram encontrados ficheiros em formato PDF em que não é possível extrair os conteúdos.
Por exemplo:
Devem garantir que os ficheiros PDF são otimizados para que seja possível extrair a informação para um processador de texto. Desta forma, garante-se que o texto pode ser lido por leitores de ecrã na ordem correta. No caso de documentos que são fotocópias, contendo apenas imagens, é possível converter os documentos para texto através do Reconhecimento Óptico de Caracteres (OCR) da Adobe.
etiqueta: NOK
Nível de conformidade:
etiqueta: NOK
Lista de evidências recolhidas:
evidência: issue #21 O sítio Web não apresenta um resumo breve do seu propósito
Não existe qualquer resumo do propósito, pelo que deve ser adicionado.
Figura 1 - Página inicial da CM Alcobaça
Como referência de uma boa prática, é possível verificar no website acessibilidade.gov ou da Câmara Municipal de Valongo que o seu propósito está escrito no topo da página.
etiqueta: N/A
Lista de evidências recolhidas:
evidência: issue #46 R 1.2 - Conteúdo
Os termos mais complexos têm uma definição agregada.
– ver requisito 1.2 na lista Conteúdo
etiqueta: NOK
Lista de evidências recolhidas:
evidência: issue #23 Os documentos longos não têm um índice no topo com hiperligações internas para o mesmo
Nas páginas consideradas longas, como a Exposições temporárias não existem um índice com hiperligações para cada secção interna dessa página.
Figura 1 - Página Exposições temporárias é uma página longa.
Para facilitar a navegação em páginas longas, com várias secções de conteúdos, deve existir um índice no topo da página. Esse índice deve conter hiperligações para as várias seções que existem.
etiqueta: NOK
Nível de conformidade:
etiqueta: NOK
Lista de evidências recolhidas:
evidência: issue #65 A sequência de tabulação no campo das datas e no botão de pesquisa não segue a sequência de preenchimento
A sequência de tabulação entre campos segue a sequência de preenchimento.
– ver requisito 1.1 na lista Transação
O critério não cumpre porque:
Se optaram por não corrigir este issue, devem evidenciar estes problemas na checklist de Transação na Declaração de Acessibilidade.
etiqueta: N/A
Lista de evidências recolhidas:
evidência: issue #66 R 1.2 - Transação
Os formulários com mais de 2 ecrãs de altura devem ser distribuídos por várias páginas.
– ver requisito 1.2 na lista Transação
etiqueta: N/A
Lista de evidências recolhidas:
evidência: issue #67 R 1.3 - Transação
Os formulários com mais de uma página têm a sequência de passos ilustrada.
– ver requisito 1.3 na lista Transação
etiqueta: N/A
Lista de evidências recolhidas:
evidência: issue #69 R 2.2 - Transação
É usada revelação progressiva em vez de campos inativos.
– ver requisito 2.2 na lista Transação
etiqueta: N/A
Lista de evidências recolhidas:
evidência: issue #85 R 4.2 - Transação
As ações destrutivas nunca devem ser permanentes, deve ser sempre possível desfazer a operação.
– ver requisito 4.2 na lista Transação