Relatório Avaliação da Candidatura da Câmara Municipal de Valongo

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

Lista de evidências recolhidas:

• evidência: Não é possível navegar para a opção seguinte do menu sem percorrer as subopções

  etiqueta: chk 10 webetiqueta: melhoriaetiqueta: R 1.2

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

  • Ver requisito 1.2 da lista 10 aspetos

  As opções do menu não devem abrir automaticamente quando recebem o foco através das tecnologias de apoio ou do teclado. Este comportamento faz com que os utilizadores tenham que percorrer todas as subopções antes de conseguirem avançar para a próxima opção do menu. Por exemplo, quando navegamos pelo menu utilizando o teclado, não conseguimos aceder as subopções de "Participar" sem antes percorrer por todas as subopções de "Município" e "Diretório de Serviços".

  

  É necessário percorrer todas as subopções antes de aceder a opção "Participar" do menu

  Recomendamos que as opções de 2º nível do menu fiquem fechadas até o utilizador escolher aceder às subopções. Para isso, é necessário criar um evento no Javascript que gerencie a abertura e fecho das opções do menu pelo atributo aria-expanded.

  Para mais informações partilhamos também um exemplo de construção do menu da W3C.

• evidência: As opções do menu não apresentam uma indicação visual de que contêm subopções

  etiqueta: chk 10 webetiqueta: melhoriaetiqueta: R 1.2

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

  • Ver requisito 1.2 da lista 10 aspetos

  As opções do menu devem apresentar uma indicação visual para informar que contêm subopções. Isso permite que as pessoas que navegam com teclado e leitor de ecrã, e que utilizam a visão ou parcial, identifiquem de forma clara as opções disponíveis.

  Embora o menu do website tenha uma sinalética apresentado no menu pelo círculo (●), essa sinalética não possui o objetivo de indicar quais opções contém subopções.

  

  Opções do menu não contém uma sinalética visual que indica que contém subopções

  Recomendamos indicar visualmente quais opções do menu contém subopções. Para isso, podem incluir uma sinalética visual, como por exemplo, uma seta para baixo quando o menu estiver fechado, e seta para cima quando o menu estiver aberto.

etiqueta: N/A

Lista de evidências recolhidas:

• evidência: Não existem imagens-link no menu

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

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

  • Ver requisito 1.3 da lista 10 aspetos

  Não identificamos a existência de imagens-link no menu.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: Há cabeçalhos incorretamente atribuídos

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 2.2

  Existe uma marcação hierarquizada de títulos e subtítulos na página <h1>...<h6>.
  – ver requisito 2.2 na lista 10 aspetos
  Existem cabeçalhos que não configuram secções, e devem ser removidos.

  

  Figura 1 - Um dos cabeçalhos da secção "Alertas e Avisos"

  Como é possível observar na figura, o cabeçalho de nível 2 “Interrupção de trânsito em Valongo - Festas da Cidade e Procissão de S. Mamede” constitui-se, atualmente, como uma subsecção da secção “Alertas e Avisos”.
  Este cabeçalho, bem como todos os demais da secção “Alertas e avisos” (que obedecem à mesma estrutura), encontram-se imediatamente uns a seguir aos outros, sem qualquer texto entre eles, pelo que não faz sentido que sejam considerados como início de novas secções. Para além disso, cada cabeçalho desta secção tem um link que o precede, e em que se verifica que o texto de cada link é igual ao texto de cada cabeçalho.

  Pelo exposto, e neste caso em particular, recomendamos a remoção completa dos elementos <h2> (inclusive o seu texto) dos itens da secção “Alertas e Avisos”.

  Existem outras secções na página inicial que têm a mesma estrutura da secção “Alertas e Avisos”, com os textos dos links igual aos textos dos cabeçalhos, e em que esses cabeçalhos e respetivos textos devem ser removidos, não só por não serem considerados secções, mas também para evitar a duplicação de informação.

  Referimo-nos aos cabeçalhos existentes nas seguintes secções:

  • Secção "EVENTOS EM DESTAQUE";
  • Secção "Acessos Rápidos";
  • Secção "Portais CMV", "Valongo, um território a descobrir!";
  • Secção que se estende desde "Saiba quanto custou" a "Mensagem do Presidente";
  • Secção que se estende desde "Publicações" a "Valongo em Agenda";
  • Secção que se estende desde "Apoios Comunitários" a "Inquéritos e Inscrições";
  • Secção que se estende desde "Loja Interativa de Turismo" a "Valongo Energy Hub";
  • Secção que se estende desde "Ferrovia" a "Bugios e Mourisqueiros".

  Diretamente relacionado com este ticket está o ticket “R 8.3 - 10 Aspetos - Existem links em cards e em listas de links estruturados de forma incorreta”, que recomenda a restruturação dos links destas mesmas secções de modo a torná-los visíveis.

  Para mais informações sobre como estruturar os cabeçalhos, partilhamos a seguir um ficheiro com notas de acessibilidade identificando os únicos locais que devem ser atribuídos cabeçalhos.

  

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: Existem tabelas com vários tipos de informação no cabeçalho

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 3.1

  As células que constituem os cabeçalhos da tabela estão marcadas com o elemento <th>.
  – ver requisito 3.1 na lista 10 aspetos

  Os controlos que permitem recuar e avançar um mês, presentes na tabela associada ao campo “Data de nascimento” do formulário INSCRIÇÃO - LAN HOUSE, devem ser colocados fora da tabela.

  

  A leitura da tabela por utilizadores de leitores de ecrã fica mais simples se apenas contiver a funcionalidade relativa aos dias do calendário, ficando os botões de recuo e avanço entre meses fora da tabela.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: O elemento `` está a ser ocultado pelo CSS

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 3.2

  A legenda da tabela está marcada com o elemento <caption>
  – ver requisito 3.2 na lista 10 aspetos

  A tabela que estrutura o calendário associado ao campo “Data de nascimento” do formulário INSCRIÇÃO - LAN HOUSE tem o seu elemento <caption> escondido através da propriedade display: none do css.

  

  O uso da propriedade display: none pode gerar problemas de acessibilidade, pois além de esconder visualmente o elemento ela esconde também das tecnologias de apoio. Existem propriedades em CSS que permitem ocultar o conteúdo de forma visual, mantendo-o acessível às tecnologias de apoio.
  Recomendamos evitar o uso de display: none e como alternativa, sugerimos utilizar uma classe .hidden para esconder o conteúdo visualmente, mantendo-o acessível aos leitores de ecrã. Para mais informações, partilhamos o artigo CSS em Ação: Conteúdo Invisível apenas para Utilizadores de Leitor de Ecrã.

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

Lista de evidências recolhidas:

• evidência: As caixas de seleção não possuem legenda e etiquetas associadas ao campo

  etiqueta: chk 10 webetiqueta: melhoriaetiqueta: R 4.1

  Quando a legenda está corretamente associada ao grupo de opções, o leitor de ecrã consegue anunciar a legenda complementando a opção que está com foco:

  

  No entanto, a caixa de seleção do formulário de newsletter não apresenta o mesmo comportamento. Para além de ocultar o elemento input type="checkbox" das tecnologias de apoio — o que indica que não existe uma associação explícita entre a label e o input (uma vez que o input "não existe" pois se encontra com display: none) — está a ser utilizada uma lista ul li para agrupar as opções, sendo muito provável que esta esteja a ser usada apenas para fins de apresentação do layout:

  

  Recomendamos rever a caixa de seleção para garantir que a legenda está corretamente associada às respetivas opções. É necessário garantir a associação entre a label e o campo input, e verificar que as opções são acessíveis através do teclado, utilizando as teclas TAB e SHIFT+TAB.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: Existem imagens que estão com texto alternativo incorreto

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 5.1

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

  Na página inicial da CM Valongo é possível identificar imagens com texto alternativo no idioma inglês:

  

  Texto alternativo icondownload na imagem

  Para além disso, é possível identificar imagens com texto alternativo inapropriado e que deveriam ser decorativas:

  

  Recomendamos rever as imagens do website para garantir que texto alternativo transmita uma informação no mesmo idioma da página e as imagens tenham o texto alternativo que informe o utilizador ou que tenham seu texto alternativo preenchido como nulo (alt="").

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

Lista de evidências recolhidas:

• evidência: O organograma possui descrição de díficil localização

  etiqueta: chk 10 webetiqueta: melhoriaetiqueta: R 5.2

  O gráfico é acompanhado de uma descrição longa.
  – ver requisito 5.2 na lista 10 aspetos

  Na página Organograma, é apresentado um link que permite aceder a descrição em texto do Organograma. No entanto, o link esta após um bloco de texto e sua localização não está próxima da imagem:

  

  Para além disso, quando acedemos ao link, é apresentado um diretório da página documentação com 4 ficheiros PDF. Dificultando o acesso ao texto alternativo, pois será necessário o utilizador procurar a informação nos ficheiros:

  

  É fundamental disponibilizar a informação de forma clara e direta ao utilizador. Quando se tratar de um link, este deve estar associado ou próximo da imagem e fornecer a informação necessária de forma imediata, sem obrigar o utilizador a procurar em documentos PDF .

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

Lista de evidências recolhidas:

• evidência: Existem imagens-link com texto alternativo em inglês

  etiqueta: chk 10 webetiqueta: melhoriaetiqueta: R 5.3

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

  Na página inicial, os controles de avançar e voltar do carrosel possuem texto alternativo em inglês:

  

  Recomendamos que o texto alternativo das imagens-link estejam no mesmo idioma do website.

etiqueta: NOK

Lista de evidências recolhidas:

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

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 7.2

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

  As legendas automáticas fornecidas pelo Youtube, utilizam recursos de reconhecimento de voz que tem 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á sendo apresentado.

  Na página Vídeos são apresentados vídeos que contém uma legenda aberta e uma fechada sendo esta gerada automaticamente pelo Youtube e apresentada na transcrição. No vídeo Documentário - Hóquei Um percurso sobre rodas a legenda fechada e transcrição não informa corretamente o conteúdo do vídeo:

  

  Legenda fechada informa "João em viveiro dos jogadores" sendo que o correto é "Valongo foi um viveiro de jogadores"

  Recomendamos reverem os vídeos para garantir que a legenda fechada e transcrição estejam igual a legenda aberta embutida nos vídeos.

• evidência: Não é possível ler a legenda do vídeo na página

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 7.2

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

  Na página a Mensagem do Presidente, encontram-se disponíveis legendas abertas e legendas fechadas. Contudo, nenhuma das opções é visível, uma vez que o vídeo está incorporado num formato demasiado reduzido. Esta limitação impede a visualização adequada das legendas e não permite expandir o vídeo diretamente na página do website forçando o utilizador a sair do website para assitir ao vídeo no Youtube:

  

  Opção modo de ecrã inteiro desativado na página do website

  Recomendamos que o vídeo seja apresentado num tamanho que possibilite a leitura nítida das legendas.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: Uso inapropriado da tag "abbr"

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 8.3

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

  A tag abbr está a ser utilizada nos formulários para indicar o significado do asterisco. No entanto, essa utilização é inapropriada. Para além de a estrutura estar oculta das tecnologias de apoio através do atributo aria-hidden, o atributo title está sendo substituído pela span:

  

  Recomendamos refazerem o texto que explique de forma clara o significado do asterisco, como por exemplo: "Os campos marcados com * são de preenchimento obrigatório". Nesse cenário não é necessário o uso da tag abbr:

  

  Exemplo

  Caso optem em manter a tag, é necessário garantir que a tag esteja visível e seu significado esteja informado através do title.

• evidência: Existem links usados como botões

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 8.3

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

  No formulário SUBSCRIÇÃO DE NEWSLETTERS está a ser utilizado um link para submissão.

  

  Figura 1 - Link de submissão de formulário usado como botão

  Enquanto que os links servem para acesso a recursos, os botões servem para executar ações, sendo por isso mais correto que a ação de submissão do formulário seja realizada por um botão.
  Dessa forma, para além de ser usado o elemento adequado, é mantida a coerência com todos os outros formulários que já usam um botão para submeter a informação. Para além disso, esta mudança torna mais eficiente a navegação de utilizadores de leitores de ecrã, pois conseguem, apenas com uma tecla de navegação rápida, chegar a todos os botões de submissão de formulários, ao invés de terem de adivinhar o tipo de estrutura com que foi codificado cada controlo de submissão.
  Pelo exposto, recomendamos a utilização do elemento <input> nativo como controlo de submissão do formulário, e a utilização de css para estilizar esse botão de modo a ficar com o aspeto do link que atualmente existe.

• evidência: Existência de checkboxes personalizadas que não são focadas por teclado nem anunciadas por leitores de ecrã

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 8.3

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

  As checkboxes que representam as newsletters passíveis de ser subscritas, no Formulário de Subscrição de Newsletters, são personalizadas com elementos <span> sem qualquer enriquecimento de acessibilidade. Tal facto impede, não só que essas checkboxes sejam focadas com o teclado (tab e shift+tab), mas também com que o tipo de controlo e estado sejam anunciados pelos leitores de ecrã.

  

  Figura 1 - Checkbox personalizada com um elemento span

  Devemos enfatizar que este problema é crítico para utilizadores exclusivos de teclado e para utilizadores de leitores de ecrã.

  Os primeiros não conseguem focar as checkboxes utilizando tab e shift+tab. Os segundos não conseguem saber qual o estado de cada checkbox, e mesmo que pressionem a tecla espaço em cada item, não percebem se houve alteração do estado.

  Recomendamos a substituição destas checkboxes por checkboxes nativas, pois são mais familiares aos utilizadores, permitem o anúncio pelos leitores de ecrã e têm menor propensão a erros comparativamente às checkboxes personalizadas.

  Caso pretendam continuar com as checkboxes personalizadas, a forma mais fácil é garantirem que os elementos <input type="checkbox"> correspondentes são escondidos apenas visualmente (e não para as tecnologias de apoio), para que as checkboxes possam ser focadas por teclado e anunciadas às tecnologias de apoio como se de controlos nativos se tratassem.

• evidência: existência de notícias incorretamente distribuídas por várias listas

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 8.3

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

  Na secção notícias da página inicial, as notícias estão distribuídas por várias listas.

  

  Figura 1 - Notícias distribuídas por três listas

  Como é possível observar na figura, as notícias estão distribuídas por três listas: a primeira lista com as cinco notícias do carrossel, a segunda com duas notícias e a terceira com quatro notícias.

  Semanticamente, o que faz sentido é a agregação de todas as notícias numa única lista, até porque
  não parece haver nenhuma característica que seja diferente nas notícias das várias listas.

  Pelo exposto, recomendamos a agregação de todas as notícias numa única lista. Quanto muito podem existir duas listas, caso seja pretendido que o carrossel não contenha todos os elementos. Nessa situação, uma lista conterá as notícias a constar do carrossel, e a outra lista conterá as restantes notícias.

• evidência: Texto dos links referenciado em vários locais

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 8.3

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

  O texto das hiperligações do menu principal é referenciado em vários locais.

  

  Figura 1 - Composição de um link do menu principal

  Como se pode observar na figura, o texto de cada hiperligação do menu principal está repetido em três locais:

  • No atributo aria-label de cada elemento <a>;
  • No atributo title de cada elemento <a>;
  • Num elemento <span aria-hidden="true"> inserido dentro do <a>.
    Consideramos esta solução desnecessariamente complexa para o problema que procura resolver, além de tornar o código confuso e propenso a erros.
    As boas práticas recomendam que o texto de cada hiperligação exista apenas uma vez, diretamente no elemento <a>, de forma a estar visível no ecrã e acessível pelas tecnologias de apoio (sem o atributo aria-hidden).
    Neste cenário, os atributos aria-label e title tornam-se dispensáveis, simplificando o código e tornando-o mais fácil de manter.
    Recomendamos a revisão do conteúdo de todos os links de forma a que contenham o texto diretamente em cada elemento <a>, eliminando outros locais onde esse texto apareça.

• evidência: Existem links em cards e em listas de links estruturados de forma incorreta

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 8.3

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

  Na página inicial existem links em cards e em listas de links que não estão estruturados de forma apropriada.

  

  Figura 1 - link estruturado incorretamente num card

  Como se pode observar na figura, o card “Apoios Comunitários” é constituído por um link, uma imagem e um cabeçalho, em que o texto do link está oculto para todos os visitantes e o cabeçalho sobrepõe-se ao link servindo o seu texto como texto desse link. Estruturalmente, o link deve, só por si, desempenhar a sua função, sem elementos auxiliares.

  Este problema acontece na página inicial, nos seguintes cards:

  • Em todos os cards da secção que se estende desde " Apoios Comunitários" a " Inquéritos e Inscrições";
  • Em todos os cards da secção “EVENTOS EM DESTAQUE”;
  • Em todos os cards da secção “Valongo, um território a descobrir!”;
  • Em todos os cards da secção que se estende desde "Ferrovia" a "Bugios e Mourisqueiros".
    O mesmo problema verifica-se também nas seguintes listas de links:
  • Na lista de links da secção que se estende desde "Loja Interativa de Turismo" a "Valongo Energy Hub";
  • Na lista de links da secção “Portais CMV”
    Posto isto, recomendamos que, para cada link de cada card: e para cada link das listas de links:
  • seja eliminada a classe link-hidden do div que contém o texto de cada link;
  • Seja eliminado o atributo aria-label de cada elemento <a>, de forma a que o texto do link seja referenciado apenas pelo conteúdo da div encaixada nesse elemento <a>.

  Diretamente relacionado com este ticket está o ticket “R 2.2 - 10 Aspetos - Há cabeçalhos incorretamente atribuídos”, que recomenda a remoção de todos os cabeçalhos existentes nestas mesmas secções.

• evidência: O formulário não informa as etapas para os leitores de ecrã

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 8.3

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

  O preenchimento do formulário da Ficha de Inscrição de Voluntários/as está dividido em etapas. Visualmente, é possível distinguir três fases: por preencher, em preenchimento e preenchido:

  

  Formulário da Ficha de Inscrição de Voluntários/as apresentando as fases visualmente de formas diferentes

  Essa distinção não é informada para os leitores de ecrã, isso faz com que não seja possível identificar o status de preenchimentos das etapas:

  

  Identificação foi preenchido e não está sendo informado para os leitores de ecrã

  

  Área de interesse está a preencher e não está sendo informado para os leitores de ecrã_

  

  Atividade de voluntariado em falta preencher não está sendo informado para os leitores de ecrã

  Recomendamos rever todos os formulários dividos por etapas para garantir que o status de preenchimento seja informado também para as tecnologias de apoio. Partilhamos um exemplo de formulário multi step da W3C que pode ajudar.

• evidência: Existem carrosséis estruturados de forma incorreta

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 8.3

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

  Os itens da secção “Alertas e Avisos” funcionam segundo uma dinâmica de carrossel, que deve ser corretamente estruturado.

  

  Figura 1 - carrossel da secção "Alertas e Avisos"

  Verificamos que a passagem automática dos itens não pode ser pausada, nem colocando o foco sobre os mesmos, nem através de um botão que efetue essa pausa, o que dificulta a leitura dos itens.
  O carrossel das notícias também precisa de estar acessível.

  

  Figura 2 - Carrossel da secção "Notícias"

  Para além de não informar quantos itens fazem parte do carrossel, não permite pausar a passagem dos itens.
  Recomendamos que seja indicado visualmente o número de elementos de cada carrossel, e que a navegação seja exclusivamente controlada pelo utilizador, que pode ser através de dois botões para avançar e retrocedera e da inclusão de um botão que permita pausar a passagem dos itens.
  Para mais informações é possível consultar os artigos Carousel Structure e Carousel (Slide Show or Image Rotator) Pattern do W3C.

• evidência: Existem controlos incorretamente enriquecidos com acessibilidade

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 8.3

  O campo “Tipo de Formulário” do formulário SUGESTÕES / EXPOSIÇÕES / RECLAMAÇÕES / ELOGIOS foi enriquecido com atributos de acessibilidade de forma incompleta e incorreta.

  

  _Figura 1 - Combobox personalizada com um um elemento <input> enriquecido com acessibilidade de forma incorreta

  Como é possível observar na figura, o campo input foi dotado com o atributo role=”combobox”, o que faz com que que a sua semântica seja a de uma combobox, sendo esse o tipo de controlo que é anunciado pelas tecnologias de apoio.

  No entanto, a navegação pelas opções da suposta combobox não funciona como numa combobox nativa, e isso constata-se claramente quando navegamos com as setas e os elementos não são automaticamente anunciados pelos leitores de ecrã.
  Assim, os utilizadores destas tecnologias têm de efetuar um esforço tremendo para entenderem o mapa mental de navegação subjacente a este controlo, e nem sempre isso é possível. Por exemplo, o leitor de ecrã NVDA só anuncia o elemento selecionado após ser pressionada a tecla tab, mas não em todas as situações.
  Associado à combobox está um botão “×” que, ao ser clicado, inibe a combobox de transmitir ao leitor de ecrã qual o item que ficou selecionado.

  Recomendamos a reformulação de todas as comboboxes deste género, de modo a torná-las controlos nativos, e com isso mais simples de manter e navegar. Caso as comboboxes tenham especificidades que não sejam atendidas pelos elementos <select> nativos, recomendamos a sua adaptação de acordo com um dos exemplos de boas práticas da W3C, onde podem consultar um exemplo de combobox acessível e hiperligações que remetem para outros tipos de comboboxes igualmente acessíveis.

• evidência: Existem elementos com a semântica incorreta

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 8.3

  Os elementos da página devem estar identificados com a semântica de HTML certa para que sejam interpretados corretamente pelas tecnologias de apoio.

  Na página Vídeos, está sendo utilizado modais para apresentar os vídeos da página. Os seus respetivos controles de avançar e fechar estão sendo construídos por div genéricas o que impossibilita a sua seleção pelos teclado e leitores de ecrã. Para além disso, os ícones estão inseridos via CSS o que fazem sumir quando desligamos o CSS:

  

  Controles de avançar e voltar da modal construídos por div e ícones inseridos via CSS

  No formulário Biblioteca Humana - Ficha de avaliação é possível identificar que a funcionalidade de remover a opção selecionada está sendo construída como uma span ao invés de ser um elemento interativo do tipo button. Isso faz com que também não seja acessível pelo teclado:

  

  Recomendamos utilizarem elementos nativos do HTML, como links a e botões button para garantir que esses elementos interativos sejam acessíveis por outras formas além do rato.

• evidência: Existem conteúdos que não estão estruturados como lista de forma apropriada

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 8.3

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

  Os breadcrumbs das páginas interiores estão identificados como uma lista não ordenada ul li ao invés de ser uma lista ordenada ol li:

  

  A ordem da informação apresentada no breadcrumb é importante. Por esse motivo, recomendamos que seja implementado como uma lista ordenada (ol e li). Para além disso, sugerimos que o breadcrumb seja definido como um elemento de navegação (nav) com a devida nomenclatura. Tal pode ser feito através da utilização do atributo aria-label="Você está aqui".

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: O foco não é direcionado para dentro da modal

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

  Quando uma modal é aberta, o foco do teclado e leitor de ecrã 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 de Vídeos, para cada vídeo abre uma modal e o foco do leitor de ecrã não é automaticamente direcionado para dentro do seu conteúdo:

  

  Foco do leitor de ecrã encontra-se abaixo da modal em outro vídeo

  Recomendamos ajustar o foco para que, ao abrir a modal, o cursor seja automaticamente direcionado para o campo de pesquisa.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: O botão fechar não está acessível pelo teclado ou leitor de ecrã

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

  Na página de Vídeos, embora as modais apresentem um botão de fechar, ele não está acessível com o teclado e leitor de ecrã:

  

  Recomendamos rever o botão de "Fechar” das modais para garantir que estejam corretamente construídos e acessíveis pelo teclado e leitor de ecrã.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: O foco é perdido quando a modal é fechada

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

  Na página de Vídeos é possível identificar vídeos que são apresentados dentro de modais. Pelo navegador Safari está funcionando corretamente. No entanto, quando fechamos a modal de vídeo no Chrome utilizando a tecla ESC o mesmo retorna para a funcionalidade de ouvir o conteúdo:

  

  Foco no card para abrir a modal

  

  Ao fechar modal o foco é movido para a função de ouvir conteúdo

  Recomendamos rever todas as modais apresentadas no website para garantir que ao fechar a modal, o foco esteja no botão acionador da modal independente de qual navegador o utilizador esteja a usar.

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

Lista de evidências recolhidas:

• evidência: O ícone do menu não tem um texto descritivo

  etiqueta: chk conteúdoetiqueta: melhoriaetiqueta: R 3.2

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

  Para ser mais claro onde se encontra o menu quando está colapsado, no caso de breakpoints de tablet e mobile, orientamos que o ícone que representa o menu seja acompanhado de um texto descritivo (ex: “Menu”).

  

  Recomendamos adicionar o texto descritivo “Menu” ao ícone. Um bom exemplo a considerar é o menu do selo:

  

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

Lista de evidências recolhidas:

• evidência: O conteúdo do site não se adapta às diferentes resoluções de ecrãs

  etiqueta: chk conteúdoetiqueta: melhoriaetiqueta: R 4.2

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

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

  É possível observar que o layout do site não se adapta as resoluções menores quando também é aplicado o zoom:

  

  Página inicial com scroll horizontal, botão selecionar idioma aparece "cortado", o menu está fixo sobrepondo a outros conteúdos

  Recomendamos o layout do website tenha um comportamento responsive e adapta-se às diferentes resoluções de ecrã, sem necessidade de fazer varrimento horizontal.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: Existem formulários longos sem divisão por passos

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

  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

  Em formulários longos, com mais de 2 ecrãs de altura, deve-se garantir que a informação é pedida ao utilizador de forma faseada, dividindo os passos em várias páginas ou secções. Essa abordagem reduz a carga cognitiva permitindo que pessoas com deficiência cognitivas preencham de forma mais assertiva.

  O formulário de FUNCIONAMENTO DO CONSELHO MUNICIPAL DE EDUCAÇÃO – 2021/2025 quando navegamos na resolução desktop (1024px) é possível perceber que o seu tamanho é maior que 2 ecrãs.

  Já no formulário de Candidatura a Bolsa de Estudo da Universidade Lusófona do Porto - Ano letivo 2025/2026 acontece um cenário diferente, o tamanho dos campos é dinâmico, ou seja, ele muda de acordo com o número preenchido no campo "N.º de elementos que compõem o agregado familiar, incluindo o/a candidato". Caso o utilizador insira um número maior que 3, o formulário passa a ser muito longo para o ecrã.

  Recomendamos reverem a estrutura dos formulários mais longos, de forma a segmentar as etapas de preenchimento com um formulário baseado em etapas, como está feito também em alguns formulários do website.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: Existem campos do formulário sem legenda

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

  As legendas dos campos são breves e claras.
  – ver requisito 2.3 na lista Transação

  A legenda deve permanecer sempre visível, mesmo quando o utilizador interage com o campo. Desta forma, não precisa de se lembrar da informação, reduzindo assim o esforço cognitivo.

  Manter a label visível no ecrã, amplia-se a área de clique, o que pode beneficiar pessoas com dificuldades motoras ao selecionar um campo específico.

  No formulário de Newsletter é possível observar que a legenda do campo nome e email desaparecem quando o utilizador interage com o campo para preencher os dados pedidos.

  

  Campos nome e email apenas com placeholder visível

  Para além disso, nas caixas de seleção do formulário Newsletter não existe uma legenda atribuída a esse grupo:

  

  Caixas de seleção não possuem legenda

  Recomendamos que nos campos input sua a label esteja sempre visível, de forma a garantir que, durante o preenchimento do campo, o respetivo nome não se perca. As caixas de seleção devem ter uma legenda para informar o tipo de seleção que está sendo feita, para isso, recomendamos que seja estruturada utilizando os elementos fieldset, legend e input type="checkbox", pois o campo input type="checkbox" está estruturado no HTML, mas está sendo escondido das tecnologias de apoio, as suas respetivas caixas de seleção estão sendo inseridas via CSS.

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

Lista de evidências recolhidas:

• evidência: Não é informado aos leitores de ecrã sobre o sucesso/erro do envio de informações automaticamente

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

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

  Página do formulário de newsletter: https://www.cm-valongo.pt/subscricao-de-newsletters

  Idealmente as mensagens de status devem ser informadas automaticamente para as tecnologias de apoio assim que tiver mudanças na página. As mensagens podem ser determinadas programaticamente de modo que possam ser apresentadas para o utilizador.

  Quando submetemos o formulário de Newsletter é apresentado uma mensagem de confirmação. No entanto, o foco do leitor de ecrã retorna para o início da página e a mensagem de confirmação não é informada automaticamente.

  

  Ao submeter o formulário de newsletter o foco do leitor de ecrã retorna para o logótipo do website e a mensagem de confirmação não é informada para o leitor de ecrã

  Recomendamos rever os formulários para garantir que as mensagens de sucesso/confirmação/problema sejam automaticamente informadas para o leitor de ecrã.

etiqueta: N/A

Lista de evidências recolhidas:

• evidência: Não existem formulários que permitem ações destrutivas pelo utilizador

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

  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

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

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

Lista de evidências recolhidas:

• evidência: É necessário existir três locais de apresentação das mensagens de erro?

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

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

  No formulário PROJETO TOP é possível identificar três formas distintas de apresentação das mensagens de erro. Apesar de cada abordagem ser válida por si só, o problema reside na utilização simultânea desses três métodos, o que provoca uma sobrecarga de informação e pode dificultar a experiência do utilizador durante o preenchimento do formulário.

  

  Formulário apresenta 3 abordagens diferentes para apresentar as mensagens de erro do formulário

  Recomendamos reverem todos os formulários do website para garantir que utilizem apenas 1 abordagem e que a apresentação das mensagens de erro seja igual para todas. Como sugestão, podem optar por apresentar a mensagem de erro próxima ao seu respetivo campo.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: Existem mensagens de erro que não ajudam na resolução do problema

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

  As mensagens de erro devem mostrar os passos concretos para a resolução dos mesmos.
  – ver requisito 4.4 na lista Transação

  Os campos dos formulários devem devolver mensagens de erros explícitas sobre como resolver o problema identificado em cada campo.

  No formulário do PROJETO TOP, a mensagem de erro do campo email não explica devidamente qual é o formato a ser inserido, revelando apenas "O '5. E-mail' indicado não é válido". O campo de contacto telefónico também não explica o tipo de informação a ser inserida, revelando "O campo '6. Contacto telefónico' é obrigatório":

  

  Campo email e telefone possuem mensagens de erro que não ajudam durante o preenchimento

  Percebemos que, ao insistir em submeter o formulário com o mesmo erro nos dois campos, é apresentado uma segunda mensagem de erro por parte do navegador que explica melhor o que precisa ser preenchido:

  

  Campo email com segunda mensagem de erro explicando como preencher corretamente

  

  Campo contacto telefonico com segunda mensagem de erro explicando como preencher corretamente

  Recomendamos rever todos os formulários do website para garantir que a mensagem de erro apresentada pela primeira vez já explique para o utilizador como preencher o campo corretamente.

  Verificámos também que são utilizadas duas abordagens diferentes para apresentar os erros nos campos nos formulários. Esta duplicação de mensagens gera redundância e pode dificultar o preenchimento por parte dos utilizadores. Recomendamos que cada campo apresente apenas uma mensagem de erro clara e objetiva, garantindo que a mesma ajude utilizador na correção do preenchimento.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: Outras violações - Carregamento "automático" das páginas do website

  etiqueta: outras violações

  Verifica-se que, em determinados momentos durante a navegação no website, ocorre um recarregamento automático da página. Esta situação faz com que o foco do leitor de ecrã seja perdido, fazendo com que os utilizadores de leitores de ecrã naveguem novamente pelo conteúdo para conseguirem retomar a interação a partir do ponto onde se encontravam.

  Isso pode estar a acontecer por existir um carregamento de conteúdo via AJAX sendo necessário a equipa corrigir esse carregamento sem necessidade.

• evidência: Outras violações - Existem calendários não acessíveis por teclado

  etiqueta: outras violações

  O calendário estruturado através de uma tabela, associada ao campo “Data de nascimento” do formulário INSCRIÇÃO - LAN HOUSE, não é acessível através do teclado.

  

  Apesar de ser possível escrever a data na caixa de texto, não é possível selecioná-la utilizando o calendário, via teclado. Em particular, não é possível focar o calendário utilizando a tecla tab, nem percorrê-lo utilizando as setas direcionais.
  Eis algumas alternativas já implementadas e testadas que podem ser usadas para restruturar o componente, que podem envolver a substituição da tabela:

  • Recurso Date Picker Dialog Example da W3C, em que é usado um botão que, ao ser premido, foca o calendário;
  • Recurso DatePicker do carbon design system, que coloca o calendário na lista de elementos focáveis com o tab.
    Em ambos os exemplos é possível percorrer o calendário com as setas direcionais.

• evidência: Outras violações - A data está sendo lida de forma inapropriada pelo leitor de ecrã

  etiqueta: melhoriaetiqueta: outras violações

  A data de atualização que está a ser apresentada nas páginas do website está sendo escrita como texto no formato ano/mês/dia. Isso faz com que o leitor de ecrã anuncie a data de forma inapropriada:

  

  Voice Over informa a data como: Dois mil e vinte e cinco + barra + zero nove + barra + vinte e seis

  Para garantir a data seja corretamente interpretada pelos leitores de ecrã, recomendamos sempre que possível escreverem a data no seguinte formato: 26 de Setembro de 2025.

• evidência: A etiqueta e outros elementos estão a ser lidos repetidamente pelo leitor de ecrã

  etiqueta: outras violações

  No formulário de Sugestões, reclamações e elogios, as etiquetas dos campos estão a ser lidas de forma duplicada pelo leitor de ecrã. Esta situação ocorre em todos os formulários do website.

  

  Etiqueta "Nome (obrigatório) anunciada duas vezes pelo leitor de ecrã

  Todo o campo deve estar associado programaticamente à sua etiqueta. No entanto, o que acontece nos formulários da CM Valongo é o uso de várias técnicas para o mesmo objetivo, o que faz com que o leitor de ecrã leia a etiqueta de forma repetida. Nesse caso, recomendamos associar a etiqueta ao campo através dos atributos for e id (que já está a ser utilizado) e remover os atributos aria-labelledby e aria-describedby.

• evidência: Outras violações - Existência de nomes acessíveis de botões noutro idioma

  etiqueta: outras violações

  O nome acessível dos botões do carrossel da secção de notícias da página inicial está em inglês.

  

  Figura 1 - Botões do carrossel presente na secção notícias da página inicial

  Recomendamos a alteração dos nomes acessíveis de todos os controlos para o idioma do site.

• evidência: Outras violações - Existem ícones não coincidentes com a função dos respetivos links a que estão associados

  etiqueta: outras violações

  O ícone de “Valongo em Agenda” é um link de transferência, mas o link que lhe está associado abre uma nova página.

  

  6Figura 1 - Ícone correspondente à função "Valongo em Agenda"

  Recomendamos a substituição do ícone atual por um outro que se adeque à função que o link que lhe está associado desempenha.

• evidência: Outras violações - Existência de notícias repetidas

  etiqueta: outras violações

  Na secção notícias da página inicial Existem notícias que se repetem nas várias listas, o que dificulta a leitura da secção, principalmente por parte dos utilizadores de tecnologias de apoio, no que toca ao discernimento de quais os títulos das notícias que são diferentes dos que já foram lidos.
  Recomendamos que sejam eliminados os títulos das notícias repetidas.

• evidência: Outras violações - O link de saltar para conteúdo principal não está acessível

  etiqueta: outras violações

  O link de saltar conteúdo é uma funcionalidade que permite ao utilizador aceder diretamente ao conteúdo principal da página, evitando percorrer elementos repetitivos da parte superior (menu, ligações, pesquisa, etc.).

  Para que o link de saltar conteúdo seja acessível, é necessário garantir a sua correta implementação, a saber:

  1. Quando utilizamos a tecla TAB com o teclado ou leitor de ecrã, o primeiro item a receber foco é o link de saltar conteúdo. O link não precisa ser visível na página, no entanto, devem garantir que quando recebe o foco ele se torne visível. Para isso, recomendamos consultarem o artigo CSS em ação: Links "saltar navegação".

  

  Link de saltar conteúdo principal não é visível e acessível pelo teclado ou leitor de ecrã

  2. Ele deve ser construído estruturalmente apenas como um link. Recomendamos evitar o uso de demasiadas funções na estrutura. Para isso, é necessário remover o h1 dentro do link.

  

  Link sendo estruturado com h1 de forma inapropriada

  3. Deve ter um nome acessível que explique o seu conteúdo. Para isso, é necessário remover o aria-label="Título" e manter apenas o texto do link como nome acessível.

  

  Link de saltar conteúdo com o aria-label utilizado de forma inapropriada

  4. É necessário garantir que quando o link estiver visível, ele esteja acima do contraste recomendado (4,5:1 para texto com o fundo e 3:1 para o corpo do elemento com a cor de fundo).

• evidência: Outras violações - Existem campos opcionais que não são identificados como tal

  etiqueta: outras violações

  No formulário de Questionário de Avaliação da Satisfação dos Munícipes é possível identificar campos obrigatórios sendo informados programaticamente e com visualmente pelo asterísco (*). E no mesmo formulário, é possível identificar campos opcionais pela etiqueta e outros campos opcionais que não possuem a mesma informação na etiqueta:

  

  Campos opcionais descritos pela etiqueta e campos opcionais sem essa descrição na etiqueta

  Recomendamos rever todos os formulários para garantir que as informações sejam passadas de forma padronizada em todos os campos, como por exemplo, se o campo é opcional todos os campos devem conter (opcional) na etiqueta ou vice-versa.