Relatório Avaliação da Candidatura da Município de Oliveira do Hospital

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #6 Menus com problemas estruturais

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 1.1

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

  • Ver requisito 1.1 da lista 10 aspetos

  Notas Gerais

  • Para que a navegação seja acessível e corretamente interpretada pelas tecnologias de apoio, os elementos dos menus e submenus deverão estar todos estruturados como lista, recorrendo aos elementos <ul> e <li>.

  Menu principal com problemas semânticos

  No caso do menu principal do site da Câmara Municipal de Oliveira do Hospital, apesar de existir uma lista para as opções principais, as subopções não estão semanticamente relacionadas com os respetivos itens de nível superior. Em vez de estarem aninhadas dentro do mesmo item de lista (<li>), surgem separadas em elementos estruturais independentes (por exemplo, div ou section) que funcionam como contentores do segundo nível de navegação. (Figura 1)

  

  Figura 1- Estrutura semântica do menu principal está incorreta

  Esta implementação cria um desfasamento entre a estrutura visual e a estrutura semântica do menu. Para os utilizadores que recorrem a tecnologias de apoio, como leitores de ecrã, a relação hierárquica entre as opções principais e as subopções deixa de ser clara ou pode mesmo não ser reconhecida. Como resultado, o menu pode ser interpretado como conjuntos independentes de links em vez de uma estrutura de navegação hierarquizada.

  Do ponto de vista da acessibilidade, os menus devem refletir a hierarquia de navegação através da própria marcação HTML, utilizando listas aninhadas (<ul> dentro de <li>), o que permite que as tecnologias de apoio compreendam automaticamente as relações entre níveis de navegação.

  Recomendação de melhoria
  Recomenda-se que o menu seja reestruturado de forma a refletir corretamente a hierarquia de navegação no HTML. Cada opção principal deve corresponder a um <li> que contenha diretamente uma lista aninhada <ul> com as respetivas subopções. Desta forma, a relação entre níveis fica explícita no código e pode ser interpretada corretamente por tecnologias de apoio.

  Menu secundário não diferencia opções de primeiro e segundo nível

  O menu secundário apresenta problemas adicionais, por exemplo na página Cidade Oliveira do Hospital ao navegar pelas opções com leitor de ecrã NVDA, todas opções são lidas sem informar relações com as opções primeiro e segundo nível. (Figura 2)

  

  Figura 2- Menu secundário com análise pelo leitor de ecrã NVDA, leitura de todas as opções sem informar hierarquias

  Semanticamente apesar dos itens estarem organizados em lista, não existe comunicação semântica adequada da hierarquia. O menu secundário não está identificado semanticamente como área de navegação <nav>, estando implementado apenas como <div>. As opções de segundo nível funcionam como acordeão, mas:

  • Não informam se estão recolhidas ou expandidas.
  • Não possuem atributos ARIA que indiquem o estado (aria-expanded) ou a relação de controlo (aria-controls).

  Nas páginas interiores do website o problema é recorrente, o menu secundário apresenta problemas com o acordeão que não informa aos leitores de ecrã que está expandido/recolhido. E ainda possui os símbolos < e >, que são lidos pelos leitores de ecrã como (maior que e menor que). (Figura 3)

  

  Figura 3- Menu secundário com problemas no acordeão, leitura com NVDA como uma lista única

  
A estrutura não assegura uma navegação semanticamente robusta nem plenamente interpretável por tecnologias de apoio, além de dificultar a navegação pois utilizadores de leitores de ecrã que precisam passar por todas opções de primeiro e segundo nível mesmo sem selecionar as opções de segundo nível, sendo assim o critério não é cumprido.

  Recomendação de melhoria

  • O menu secundário deve ser reestruturado com semântica adequada ou em alternativa com padrões WAI-ARIA, utilizando o atributo <nav> identificado como menu secundário, listas hierárquicas e botões acessíveis que indiquem o estado dos acordeões através de aria-expanded e aria-controls.
  • Devem ser removidos os símbolos < e >, que são lidos incorretamente pelos leitores de ecrã, substituindo‑os por ícones visuais (ex.: setas em SVG com aria-hidden="true"). A comunicação do estado deve ser feita apenas via atributos ARIA. Estas melhorias garantem uma navegação mais clara e compatível com as tecnologias de apoio e os requisitos de acessibilidade.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #8 Menu principal com dependência de hover e invisibilidade estrutural

  etiqueta: chk 10 webetiqueta: R 1.2etiqueta: NOK

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

  • Ver requisito 1.2 da lista 10 aspetos

  Notas Gerais

  • Deve ser possível percorrer a estrutura de navegação quer com um dispositivo apontador, quer com o teclado.
  • Para que seja possível navegar de forma livre por todas as opções do menu, a navegação deve estar estruturada semanticamente de forma correta no HTML e utilizar CSS e JavaScript de forma apropriada.

  Menu principal com dependência de hover

  Não é possível selecionar as subopções do menu principal com leitores de ecrã, pois a sua disponibilização e ativação depende exclusivamente de interação com rato (hover) e não estão integradas com as opções de primeiro nível.

  Por exemplo na página inicial, ao selecionar as opções de primeiro nível não é informado aos utilizadores que a opção “Serviços” está recolhido e que existem subopções. (Figura 1)



  

  Figura 1- Menu não informa se está expandido/recolhido

  Não estando assegurada uma estrutura robusta com identificação clara de estados e relações hierárquicas, por exemplo, através de atributos ARIA como aria-expanded ou aria-haspopup. Ou seja, não existe suporte para ativação através de teclado (enter, espaço, setas direcionais). Esta implementação impede que utilizadores de tecnologias de apoio acedam às subopções da navegação.



  O comportamento do elemento é completamente diferente quando utilizamos o rato sobre o menu de navegação que apresenta uma secção que inclui as subopções. (Figura 2)

  

  Sugestão de resolução do problema

  O sub-menu não deverá abrir automaticamente quando tem o foco da tecla TAB, para não tornar obrigatório a sua leitura antes de ir para o próximo item. É necessário implementar no código um evento/script que permita ao atributo aria-expanded mostrar ou esconder as subopções. Recomenda-se criar um evento de clique que irá abrir ou fechar as sub-opções de acordo com o estado do item de 1º nível.

  • As melhorias devem garantir:

    • Que as opções de 1º nível do menu fiquem colapsadas até o utilizador escolher aceder às subopções com a tecla “Enter”.
    • Que as opções de 1º nível colapsem quando o foco do teclado não está numa delas.

    Para garantir esse comportamento, as opções de 1º nível do menu de navegação devem ter:

    • o atributo ARIA “aria-expanded” para as tecnologias de apoio identificarem que existem subopções e quando o menu está colapsado (aria-expanded=”false”) ou expandido (aria-expanded=”true”).
    • o atributo ARIA “aria-current” para as tecnologias de apoio identificarem estruturalmente em qual das opções do menu é que o utilizador se encontra.

  Para mais informação sobre boas práticas de implementação dos menus e submenus, podem consultar a página da W3C

• evidência: issue #7 Lista de opções dos contactos inacessível com teclado

  etiqueta: chk 10 webetiqueta: R 1.2etiqueta: NOK

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

  • Ver requisito 1.2 da lista 10 aspetos

  Notas Gerais

  • Deve ser possível percorrer a estrutura de navegação quer com um dispositivo apontador, quer com o teclado.

  Na página inicial do website, o botão “Contactos” apresenta uma lista de opções que é ativada através do hover do rato. No entanto, ao utilizar apenas o teclado, verifica-se um comportamento inconsistente: ao navegar com a tecla TAB, apenas é possível focar a primeira opção da lista, não sendo possível percorrer sequencialmente todas as restantes opções do submenu. Ou seja, não é possível navegar por todos os itens da lista de opções dos "Contactos" com o teclado. (Figura 1)

  

  Figura 1 - DevToold na opção "Contactos" com atributo <button> e uma lista associada inacessível por teclado

  A análise do código revela que a lista <ul> que contém as opções do menu está incorretamente aninhada dentro do elemento <button> que ativa o dropdown. Esta estrutura é semanticamente inadequada, uma vez que o elemento <button> é um elemento interativo e não deve conter no seu interior outros elementos interativos, como links <a>. Como consequência, o navegador não gere corretamente a ordem de foco dos elementos, limitando a navegação por teclado e impedindo o acesso a todas as opções do submenu.

  Esta situação compromete a navegação por teclado e não cumpre o presente requisito.

  Recomendação de melhoria

  Recomenda-se a revisão da estrutura HTML e do comportamento do menu dropdown, de forma a garantir uma navegação completa e consistente por teclado. Em particular, deve evitar-se a inclusão da lista <ul> dentro do elemento , colocando o submenu como um elemento separado e garantindo que cada opção é representada por um link focável <a> na ordem natural de tabulação.
  Adicionalmente, o menu deve poder ser aberto e percorrido através do teclado, assegurando que todas as opções ficam acessíveis através da tecla TAB. A implementação pode ainda ser reforçada com o uso de atributos ARIA apropriados, por exemplo aria-expanded, para melhorar a interpretação do componente por tecnologias de apoio.

  Sugestão de estrutura:

  <ul>
                  <li><a href="…">Home</a></li>
                  <li><a href="…">Shop</a></li>
                  <li class="has-submenu">
                          <a href="…" aria-expanded="false">Space Bears</a>
                          <ul>
                                  <li><a href="…">Space Bear 6</a></li>
                                  <li><a href="…">Space Bear 6 Plus</a></li>
                          </ul>
                  </li>
                  <li><a href="…">Mars Cars</a></li>
                  <li><a href="…">Contact</a></li>
          </ul>
  

  Com estas melhorias, será possível garantir que todas as opções dos Contactos são navegáveis e selecionáveis tanto com rato como com teclado.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #9 Imagens-link do menu com textos alternativos incorretos

  etiqueta: chk 10 webetiqueta: R 1.3etiqueta: NOK

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

  • Ver requisito 1.3 da lista 10 aspetos

  Menu principal com imagens-link mal estruturadas e com textos alternativos incorretos

  Na análise ao menu principal, verificou-se que existem imagens-link que só são visíveis quando ativadas com hover, porque as subopções não são acessíveis por teclado (conforme identificado no critério 1.2).

  As imagens-link são integradas visualmente ao menu, no entanto não estão relacionadas semanticamente na estrutura do menu. Por exemplo quando o menu é ativado por hover, ao selecionar a opção "Turismo" são apresentadas imagens que funcionam como links de navegação, no entanto são inseridas numa<div> e localizadas fora da estrutura de lista (<ul>/<li>) que contém as restantes subopções do menu. (Figura 1)

  

  Figura 1 - Imagens-link do menu principal

  Esta implementação cria um problema de coerência semântica, uma vez que visualmente fazem parte do menu, mas não estão integrados na hierarquia de navegação do menu, podendo não ser interpretadas por tecnologias de apoio como opções equivalentes às restantes subopções e consequentemente também não são percecionadas como opções de navegação para os utilizadores. Além disso o equivalente alternativo das imagens-link é pouco descritivo.

  

  Figura 2 - Imagens com textos alternativos incorretos “gráfico Oliveira do Hospital”, são anunciadas pelo leitor de ecrã NVDA

  Outro exemplo é na opção “Serviços” do menu, embora as imagens possuam atributo alt, o texto alternativo não descreve adequadamente o destino ou a função do link. No exemplo analisado, o elemento inclui aria-label="Link para cm oliveiradohospital.pt", enquanto a imagem possui alt="o que temos a oferecer". (Figura 3)

  

  Figura 3- Análise das imagens-link com DevTools, textos alternativos incorretos

  Estes textos não comunicam claramente o destino da ligação (por exemplo, a página de Serviços) nem são funcionalmente equivalentes a uma opção de navegação textual. O uso de um aria-label genérico sobrepõe-se ao alt para leitores de ecrã e acaba por fornecer uma informação pouco útil para a compreensão do conteúdo ou da ação associada ao link. Esta situação pode dificultar a navegação para utilizadores de tecnologias de apoio, que dependem de descrições textuais claras para compreender o propósito dos elementos interativos.

  Recomendação de melhoria

  As imagens que funcionam como links de navegação devem ser integradas semanticamente na estrutura do menu, preferencialmente como itens da lista de subopções <li>, garantindo que fazem parte da hierarquia de navegação. O texto alternativo das imagens deve descrever de forma clara e funcional o destino do link (por exemplo “Aceder à página de Turismo”). Caso seja utilizado aria-label, este deve fornecer uma descrição equivalente e não genérica, alinhada com o destino real da ligação. Desta forma, garante-se que todas as opções de navegação são compreensíveis e acessíveis para utilizadores de leitores de ecrã e outras tecnologias de apoio.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #10 Há páginas que não existem um título <h1> ou está atribuído incorretamente

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 2.1

  Existe um título <h1> marcado na página.
  Ver requisito 2.1 da lista 10 aspetos

  Notas gerais

  • O título principal de cada página, que sumariza o seu conteúdo, deve ser identificado como o primeiro nível dos títulos (<h1>). Não deverá ser utilizado mais do que um <h1> por página.
  • As páginas do website devem ter apenas um <h1> atribuído. Este elemento deve ser atribuído a títulos relevantes na estrutura da página, e não a textos genéricos, botões ou outro conteúdo.

  Existe mais do que um <h1> atribuído por página

  As páginas do website devem ter apenas um <h1>atribuído. Nas páginas interiores, o <h1> deve estar atribuído ao título do conteúdo principal dessa página. Já na homepage, o <h1> deve estar atribuído ao logótipo para, em conjunto com um texto alternativo correto, melhorar o SEO da página.

  No site Município de Oliveira do Hospital, foram encontradas páginas com problemas de atribuição incorreta do <h1>. Como por exemplo, na página inicial o h1 não está associado ao logotipo e sim ao título "Venha e Descubra" (Figura 1).

  

  Figura 1 - Página inicial com <h1> atribuído incorretamente, sem estar associado ao logótipo

  Há páginas sem <h1> atribuído

  Há páginas interiores do website que não existem <h1> por exemplo a página Freguesia e Turismo (Figura 2 e 3)

  

  Figura 2 - Página "Freguesia" com apenas um <h3> atribuído

  

  Figura 3 - Página "Freguesia" com apenas um <h3> atribuído

  Recomendações de melhoria

  Devem rever todas as páginas do site, de forma a confirmar que o elemento <h1> está atribuído ao título principal de cada página:

  • Na homepage, o elemento <h1> deve estar atribuído apenas ao logótipo principal
  • nas páginas interiores, o elemento <h1> dever estar atribuído aos títulos das respetivas páginas.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #11 Saltos hierárquicos de títulos e subtítulos

  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

  Notas Gerais

  • Os títulos são empregues de forma hierárquica para melhor estruturar os conteúdos, das informações mais gerais às mais particulares. Deverão ser usados de forma consistente por todo o sítio Web.Os títulos são empregues de forma hierárquica para melhor estruturar os conteúdos, das informações mais gerais às mais particulares. Deverão ser usados de forma consistente por todo o sítio Web.

  A hierarquia da marcação de títulos não está a ser respeitada

  Cada página do site deve ter apenas um título <h1>. Abaixo desse <h1> podem existir várias marcações <h2>, <h3>, e assim sucessivamente, desde que esses títulos estejam organizados de forma hierárquica, e sem saltos na hierarquia. A marcação de títulos e subtítulos nas páginas de forma hierárquica ajuda a estruturar o conteúdo de forma correta e facilita a navegação pelas secções do website com teclado e com leitores de ecrã.

  Verificou-se que existem páginas em que a hierarquia de títulos não está a ser respeitada. Por exemplo, na página Empreender + Oliveira do Hospital 2025, pois existem saltos hierárquicos de <h1> para <h3>. É necessário melhorar a hierarquia das páginas. (Figura 1).

  

  Figura 1 - Análise com a ferramenta Web Developer, página com saltos hierárquicos dos cabeçalhos

  Há páginas interiores com ordem hierárquica incorreta, com <h3> marcado antes do <h1> como na página Património Classificado (Figura 2)

  

  Figura 2 - Análise com a ferramenta Web Developer, página com ordem incorreta dos cabeçalhos

  O mesmo acontece em outras páginas interiores:


  • Gastronomia e lazer
  • Praias Fluviais
  • Freguesia Bobadela
  • Freguesia Lagares da Beira

  Recomendações
  Devem rever todas páginas do site (homepage e interiores) para garantir que respeitam a hierarquia de títulos e subtítulos, o que implica:

  • Ter 1 título <h1> (que marca o texto que representa o título da página ou, no caso da Homepage, o logo da entidade);
  • Ter as várias secções do documento marcadas com <h2>;
  • Ter as várias subseções de <h2> marcadas com <h3>, as subsecções destas com <h4> e assim hierarquicamente encadeados até <h6>;
  • Evitar ter elementos de hierarquia inferior sem um elemento de hierarquia imediatamente superior (subseções órfãs). Por exemplo, ter um <h3> sem a correspondente <h2>, ou <h4> sem a correspondente <h3>.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #15 Alguns campos de preenchimento obrigatórios não identificados com leitor de ecrã

  etiqueta: chk 10 webetiqueta: R 4.2etiqueta: NOK

  É possível identificar os campos de preenchimento obrigatório quando se usa apenas um leitor de ecrã.
  – ver requisito 4.2 na lista 10 aspetos

  Formulários (NOK)

  • Modal de login https://www.cm-oliveiradohospital.pt/
  • Formulário Sugestões, Reclamações e Dúvidas https://www.cm-oliveiradohospital.pt/municipio/documentacao-online-transparencia-municipal/

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

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

  No formulário da página Documentação online | Transparência Municipal, o ícone do asterisco dos campos obrigatórios não possui texto alternativo que informe que o preenchimento é obrigatório (ver Figura 1).

  

  Figura 1- Formulário com campos obrigatórios identificados apenas através do asterisco

  Além disso na modal de login, os campos de preenchimento não são identificados como obrigatórios. (Figura 2)

  

  Figura 2 - Formulário de login com campos obrigatórios não identificados

  Impacto na acessibilidade é que utilizadores de leitores de ecrã podem não perceber que o campo é obrigatório e símbolos isolados podem não ser interpretados corretamente.

  Recomendações de melhorias

  • Adicionar identificação textual Nome(obrigatório).
  • Caso os ícones * sejam uma imagem, deve ter texto alternativo associado que descreva que o campo é de preenchimento obrigatório, como por exemplo, alt=”Campo obrigatório”.
  • Adicionar uma legenda no início do formulário que indique claramente o significado de *.

  Formulário (OK)

  • Contacte-nos https://www.cm-oliveiradohospital.pt/informacoes/contacte-nos/Contacte-nos https://www.cm-oliveiradohospital.pt/informacoes/contacte-nos/

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #17 Imagens decorativas com textos alternativos incorretos

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 5.1

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

  Notas Gerais

  • As imagens decorativas não acrescentam informação ao conteúdo da página, costumando estar acompanhadas de uma descrição textual ou servirem para tornar a página mais apelativa. Estas imagens podem conter um texto alternativo nulo (alt=””) no HTML, ou estarem apenas como background-image em CSS.

  Há imagens decorativas com texto alternativo incorreto

  Na página Percurso Pedestre de Avô, ícones decorativos também possuem texto alternativo incorreto. Por exemplo com aria-label="Link para #", este texto gera ruído significativo para pessoas que utilizam leitores de ecrã. (Figura 1)

  

  Figura 1 - Ícones decorativos com com texto alternativo incorreto

  Além disso, observamos que estes ícones decorativos são acompanhados de informações (ex.: Partida, Chegada, Extensão, Duração, Dificuldade), onde as imagens são aplicadas como background-image dentro de um link (#). No entanto, estes elementos não têm comportamento clicável real, pois os links não conduzem a destino algum. A presença injustificada de links vazios faz com que a tecnologia assistiva anuncie elementos interativos que, na prática, não possuem função pois não possuem links atribuídos.

  Recomendação de melhoria

  Recomenda-se remover os links (#) dos ícones, já que estes não executam qualquer ação ou navegação. Os elementos gráficos devem ser tratados como imagens decorativas e, por isso, marcados com alt="" ou através de aria-hidden="true", garantindo que não sejam anunciados por leitores de ecrã. Caso exista informação relevante associada aos ícones, esta deve ser transmitida através do texto visível que já acompanha cada card (ex.: “Partida – Avô”), mantendo assim a semântica correta e evitando redundância ou ruído para utilizadores de tecnologias de apoio. Estas ações asseguram uma experiência mais clara, previsível e acessível, e eliminando elementos interativos inválidos e garantindo que apenas a informação essencial é anunciada pelos leitores de ecrã.

  Outros exemplos de imagens decorativas com textos alternativos incorretos

  Ao navegar por todo website é possível encontrar outras imagens com textos alternativos que não comunicam fielmente o objetivo do seu conteúdo ou que podem ser consideradas decorativas ou seja com alt=””.

  Por exemplo, a página Demografia e as imagens possuem texto alternativos genéricos e incorretos com alt="Oliveira do Hospital". (Figura 2)

  

  Figura 2 - Página "Demografia" com texto alternativo incorreto

  Assim como na página inicial os carrosséis de "Notícias" e "Cá acontece - Eventos a decorrer no Município" Estas imagens e ícones podem ser consideradas decorativas, pois já possuem títulos atribuídos e para reduzir ruídos de informações para utilizadores com leitores de ecrã. (Figura 3 e 4)

  

  Figura 3 - Página inicial carrossel de "Notícias" com textos alternativos incorretos

  

  Figura 4 - Página inicial carrossel "Cá acontece - Eventos a decorrer no Município" com textos alternativos incorretos

  Recomendação de melhoria

  Recomendamos a revisão das imagens não decorativas para que incluam um texto alternativo, através do elemento (alt=”exemplo de texto alternativo”).

• evidência: issue #1 Imagens com textos alternativos incorretos

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 5.1

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

  Notas Gerais

  • As imagens informativas devem incluir um texto alternativo que sirva de síntese do seu conteúdo e que seja lido pelo leitor de ecrã.
  • 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.

  Na página Ação Social Escolar 2025/2026 – Pré-Escolar e 1.º Ciclo do Ensino Básico existe uma imagem com texto alternativo incorreto alt="Oliveira do Hospital". Esse texto não comunica a informação síntese da imagem (Figura 1)

  

  Figura 1 - Imagem do programa das “Atividades de Animação e Apoio à Família" com texto alternativo incorreto

  O mesmo acontece nas página Estádio Municipal que possui uma imagem com texto alternativo incorreto alt="Oliveira do Hospital". Quando na verdade a imagem comunica sobre os “Equipamentos Desportivos do Concelho de Oliveira do Hospital” com fotografias e dimensões do campo de futebol. (Figura 2)

  

  Figura 2 - Imagem da Ficha técnica do "Estádio Municipal" com texto alternativo incorreto

  Outras páginas comtextos alternativos incorretos:

  • https://www.cm-oliveiradohospital.pt/tempestade-kristin-camara-municipal-assume-recuperacao-na-eb-de-travanca-de-lagos/
  • https://www.cm-oliveiradohospital.pt/paulo-futre-e-o-protagonista-do-video-promocional-da-festa-do-queijo-serra-da-estrela-de-oliveira-do-hospital/
  • https://www.cm-oliveiradohospital.pt/programa-casa-digna-candidaturas-2/
  • https://www.cm-oliveiradohospital.pt/municipio/historia/
  • https://www.cm-oliveiradohospital.pt/municipio/heraldica/
  • https://www.cm-oliveiradohospital.pt/servicos/desporto/equipamentos-desportivos/pavilhao-municipal/
  • https://www.cm-oliveiradohospital.pt/turismo/percursos-pedestres/percurso-pedestre-de-vale-de-maceira/
  • https://www.cm-oliveiradohospital.pt/servicos/juventude/orcamento-jovem/

  Recomendações de melhoria

  • Alterar o texto alternativo das imagem para algo que descreva o conteúdo da imagem de forma sucinta.
  • Caso seja necessário incluir uma descrição longa da imagem, esta deve ser colocada próxima da imagem, por exemplo no elemento <figcaption>, ou numa página à parte que esteja hiperligada à imagem em questão.

  Imagens destaques do banner com textos alternativos incorretos

  Nas páginas interiores do website, a animação com três imagens em destaque utiliza texto alternativo incorreto (“Clicável 1/3 2/3 3/3”), que é anunciado repetidamente pelos leitores de ecrã ao usar opções como “Pular para o conteúdo principal”. (Figura 3)

  

  Figura 3 - Imagens destaque com texto alternativo incorreto, confundem navegação com leitores de ecrã

  Este texto alternativo não descreve o conteúdo visual e cria ruído informativo para utilizadores de tecnologias de apoio.

  Recomendações de melhoria
  Recomenda‑se substituí‑lo por descrições relevantes ou remover o texto alternativo quando o elemento for meramente decorativo, garantindo uma experiência mais clara e conforme os requisitos de acessibilidade.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #18 Imagens complexas sem texto alternativo

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 5.2

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

  Notas Gerais

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

  Na página OIGP – Alva e Alvoco, foi identificada uma imagem complexa um mapa multicolorido com diversas áreas demarcadas, cujo texto alternativo está incorreto e insuficiente. O atributo alt registado ("Oliveira do Hospital") não descreve o conteúdo nem a função da imagem, impedindo que utilizadores de leitores de ecrã acedam à informação transmitida visualmente. (Figura 1)

  

  Figura 1 - Texto alternativo incorreto em gráfico complexo

  Como se trata de uma imagem com conteúdo informativo relevante para a consulta pública, a ausência de um texto alternativo adequado constitui uma falha do presente requisito.

  Recomendação de melhoria

  Substituir o texto alternativo atual por uma descrição adequada à complexidade da imagem. Caso a imagem represente informação essencial, deve ser fornecido um texto alternativo descritivo ou, preferencialmente, uma descrição detalhada num texto adjacente ou link para versão acessível do mapa. Se existir legenda ou explicação num documento complementar, esta deve ser referenciada no atributo alt (ex.: “Mapa das áreas do OIGP, descrição detalhada disponível abaixo”). Esta melhoria assegura que todos os utilizadores, incluindo pessoas com deficiência visual, possam aceder ao mesmo conteúdo de forma equitativa.

  Gráfico em Canvas com textos alternativos incorretos

  Na página Demografia , o gráfico referente à “Análise do Concelho por faixas etárias” é renderizado através de um elemento HTML Canvas, que não possui texto alternativo ou uma descrição equivalente aos dados apresentados. (Figura 2)

  

  Figura 2 - Atribuição incorreta de texto alternativo em Canvas

  Como consequência, o leitor de ecrã anuncia apenas “Gráfico clicável”, sem transmitir qualquer informação sobre as percentagens ou categorias etárias representadas. Embora exista um parágrafo anterior com dados gerais do concelho, esse texto não descreve o conteúdo específico do gráfico, o que impede utilizadores com deficiência visual de acederem à informação de forma equivalente.

  Recomenda‑se que o gráfico seja acompanhado por uma descrição textual completa, ou uma tabela alternativa ao gráfico com seus respetivos dados de origem e programaticamente associada, contendo os valores apresentados para cada faixa etária. Alternativamente, garantindo que leitores de ecrã possam interpretar os dados de forma adequada.

  Iframe de mapas interativos sem texto alternativo

  As páginas Localização e Percurso Pedestre de Avô incorporam iframes contendo mapas interativos, observamos que este elemento possui textos alternativos incorretos e não descritivos sobre as áreas em foco e objetivo dos mapas, sendo atribuídos textos incorretos aos titles e aria-label. (Figura 3 e 4)

  

  Figura 3- Atribuição incorreta do title e aria-label com valores numéricos (40.2962266, -7.9207786)

  

  Figura 4 - Atribuição incorreta do title e aria-label "Oliveira do Hospital"

  Esta ausência impede utilizadores de tecnologias de apoio de compreenderem o propósito do conteúdo incorporado, constituindo uma barreira de navegação. Além disso, os conteúdos do mapa não é plenamente acessível por teclado ou leitor de ecrã, o que pode excluir utilizadores com limitações visuais, motoras ou cognitivas e carece de alternativa equivalente.

  Recomendação de melhoria

  Atribuir aos iframes textos alternativos claros e informativos (ex.: title=“Mapa interativo do percurso pedestre de Vale de Maceira”) de forma a garantir identificação adequada por tecnologias de apoio. Para complementar disponibilizar uma descrição longa da área em que o mapa é focado e incluir um link para abrir a localização no serviço externo. Assegurando que a informação é percecionável e utilizável por todos os utilizadores.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #21 Ícones como imagens-link com texto alternativo incorreto

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 5.3

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

  Notas gerais

  • As imagens-link são links cujo conteúdo é composto por uma imagem e devem ser corretamente legendadas para serem interpretadas como texto quando são lidas pelas tecnologias de apoio. O texto alternativo deve ser curto, claro e servir de síntese do seu conteúdo.

  Nas páginas interiores do website, por exemplo a página Histórias existem imagens‑link utilizadas nos destaques que apresentam texto alternativo inadequado, originando anúncios incorretos e repetitivos pelos leitores de ecrã.

  

  Além disso, alguns destes elementos gráficos funcionam como links com ícones decorativos que não informam claramente que abrem em nova aba.

  Também foram identificados links incorretos em imagens‑link, como por exemplo ao selecionar a opção “Boletim Municipal” e na página Guia de Turismo Ativo, que direcionam o utilizador para páginas externas com erro de conteúdo não encontrado. (Figura 2)

  

  Na página OIGP – Alva e Alvoco Foi identificado que o ícone correspondente ao contacto telefónico utiliza um atributo aria-label com HTML embutido (aria-label="Telefone"). Esta implementação viola as boas práticas de acessibilidade, pois o atributo ARIA deve conter apenas texto simples. Como resultado, o leitor de ecrã lê literalmente as etiquetas HTML, produzindo algo semelhante a: “menor que b maior que Telefone menor que barra b maior que”, o que gera ruído e compromete a compreensão por utilizadores com tecnologias de apoio.

  

  Recomendações de melhorias
  Recomenda‑se substituir os textos alternativos genéricos por descrições adequadas ao conteúdo das imagens ou removê‑lo quando forem meramente decorativas.

  • Corrigir o conteúdo do aria-label por texto limpo, sem qualquer marcação HTML, garantindo uma leitura clara e objetiva, por exemplo: aria-label="Telefone" ou uma versão mais descritiva como aria-label="Contacto telefónico: 238 602 444".
  • Os ícones utilizados em imagens‑link devem incluir indicação programática de que o destino abre em nova aba, podendo ser reforçado através de texto visível ou aria-label apropriado.
  • Todos os links associados às imagens devem ser verificados e corrigidos para garantir que direcionam para o conteúdo pretendido, eliminando erros de página e assegurando uma navegação fiável e acessível.

• evidência: issue #20 As imagens funcionais/informativas possuem um texto alternativo incorreto

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 5.3

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

  Notas Gerais

  • As imagens informativas devem incluir um texto alternativo curto , claro e que sirva de síntese do seu conteúdo. Caso seja necessário adicionar uma descrição mais longa à imagem, existem regras específicas para tal.

  Imagens-link do rodapé e redes sociais com texto alternativo incorreto

  No rodapé do website, a imagem-link “Livro de Reclamações” utiliza um texto alternativo incorreto (alt="Oliveira do Hospital"), que não descreve adequadamente o conteúdo nem o destino da ligação a página externa “Livro de Reclamações”. (Figura 1)

  

  Além disso, na página de Notícias, identificamos que as imagens-link das redes sociais possuem texto alternativo em inglês. (Figura 2)

  

  Textos alternativos das redes sociais em uma língua diferente do website aria-label="Share on facebook", aria-label="Share on twitter", aria-label="Share on linkedin", aria-label="Share on linkedin" e aria-label="Share on whatsapp". Esta prática prejudica a perceção da funcionalidade das imagens-link por utilizadores de leitores de ecrã e viola o presente requisito.

  Recomendação de melhoria


  • O texto alternativo deve corresponder à língua do site em questão.
  • Corrigir os textos alternativos da imagens-links para que descrevam corretamente os seus conteúdos e para refletir claramente o propósito e o destino dos links por exemplo: alt="Livro de Reclamações, abre em nova janela".

• evidência: issue #19 Imagens-link com texto alternativos incorretos

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 5.3

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

  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.

  Logotipo com texto alternativo incorreto

  Na página inicial, o logotipo do Município apresenta-se como uma imagem-link, no entanto seu texto alternativo está incorreto aria-label="Link para cm oliveiradohospital.pt" pois é descrito como um link externo, quando refere-se a página atual. (Figura 1)

  

  Além disso, nas páginas interiores o logotipo como uma imagem-link tem a função de retornar à página inicial. Mas com o texto alternativo atual aria-label="Link para cm oliveiradohospital.pt", o utilizador pode não perceber que é possível utilizar este elemento para retonar a página inicial. (Figura 2)

  

  Ainda na página inicial, do website o carrossel de destaque apresenta imagens que promovem iniciativas, campanhas e eventos do município. No entanto, estas imagens são implementadas como elementos clicáveis, mas os respetivos links são inválidos (utilizam href="#") e conduzem apenas ao topo da página. Além disso, cada imagem possui o atributo aria-label="Link para #" e um alt="site 940x315 textos alternativos incorretos, sem significado e que não descrevem o conteúdo real apresentado. (Figura 3)

  

  Este tipo de implementação cria múltiplos problemas de acessibilidade:

  • os leitores de ecrã anunciam links sem função real, causando ruído e confusão;
  • a ausência de textos alternativos adequados impede que pessoas cegas ou com baixa visão compreendam a natureza do evento ou iniciativa exibida;
    a estrutura do carrossel não comunica a finalidade informativa das imagens, prejudicando a perceção e navegabilidade.

  Recomendação de Melhoria
  Recomenda-se corrigir a implementação do carrossel, assegurando que cada imagem associada a um evento ou iniciativa do município remete para uma página ou conteúdo relevante. Sempre que a imagem for verdadeiramente um elemento de navegação, o link deve ser real e conter um aria-label descritivo e significativo, por exemplo: “Mais informações sobre a Festa do Queijo”. Caso não exista destino associado, a imagem não deve ser transformada em link. Nessas situações, deve ser apresentada apenas como conteúdo informativo, com texto alternativo equivalente que descreva o evento ou iniciativa representada.
  Além disso, recomenda-se que o carrossel seja estruturado com semântica acessível, disponibilizando controlo de navegação e garantindo que os conteúdos são facilmente compreendidos por qualquer utilizador, incluindo quem utiliza tecnologias de apoio.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #22 O texto normal não tem contraste suficiente

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 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.
  – ver requisito 6.1 na lista 10 aspetos

  Notas Gerais

  • Deve assegurar-se no corpo do documento que o rácio de contraste entre a cor do texto e a cor de fundo é, no mínimo, de 4,5:1, de forma a assegurar a sua legibilidade para que pessoas com baixa visão consigam ler o texto.Deve assegurar-se no corpo do documento que o rácio de contraste entre a cor do texto e a cor de fundo é, no mínimo, de 4,5:1, de forma a assegurar a sua legibilidade para que pessoas com baixa visão consigam ler o texto.

  Na página Serviços os textos da opções dos tipos de serviços disponíveis apresentam problemas de contraste com uma taxa de 2,48:1 nas combinações de cores #9E9E9E (cor de primeiro plano) e #F8F6F7 (cor de plano de fundo)

  

  Figura 1- Análise de contraste com ferramenta WAVE na página “Serviços”

  Na página inicial, apresenta a modal de cookies com problemas de contraste nos textos dos botões “Personalizar”, “Rejeitar” e “Aceite tudo” nas combinação de cores #FCB829 (cor de primeiro plano) e #FFFFFF(cor de plano de fundo). (Figura 2) 



  

  Figura 2- Modal dos Cookies com problemas de contraste

  A mesma combinação de cores é utilizada em outros textos no website, por exemplo nos textos dos acordeões da página Documentação online | Transparência Municipal com as cores inversas #FFFFFF(cor de primeiro plano) e #FCB829(cor de plano de fundo) também não passam na avaliação de contraste.

  Recomendações

  • Recomendamos a revisão das cores das páginas para garantir os valores mínimos de contraste do texto normal, principalmente nos pares de cores indicadas.
  • Caso exista texto normal com pouco contraste, em que as cores utilizadas sejam as mesmas do logótipo da entidade, recomendamos a substituição dessas cores por outras que garantam um contraste mínimo de 4,5:1. Por exemplo, podem ser usados tons semelhantes ao do logotipo ou outras cores da identidade gráfica da marca.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #23 Alguns textos grandes não tem contraste suficiente

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 6.2

  O rácio de contraste entre a cor do texto de tamanho grande (maior ou igual que 18 pontos ou maior ou igual que 14 pontos negrito) e a cor do fundo é superior a 3:1.
  – ver requisito 6.2 na lista 10 aspetos

  Notas Gerais

  • Os textos de tamanho superior a 18 pontos, ou os textos de tamanho superior a 14 pontos mas a negrito, devem assegurar um rácio de contraste mínimo de 3:1 entre a cor do texto e a cor do fundo, para que as pessoas com baixa visão consigam ler o texto.

  Na página inicial o texto grande “Visite Oliveira do Hospital” apresenta problemas de contraste com a combinação de cores #FCB829 (cor de primeiro plano) e #F8F6F7(cor de plano de fundo) (Figura 1)

  

  Figura 1- Texto grande na página inicial não passa na avaliação com taxa de contraste (1,6:1)”

  Ainda na página Inicial os textos grandes do carrossel de eventos, na interação dos textos com hover utilizam a mesma combinação de cores #FCB829 (cor de primeiro plano) e #F8F6F7(cor de plano de fundo) que não passam na avaliação de contraste. (Figura 2)

  

  Figura 2- Texto grande do carrossel de eventos na página inicial não passa na avaliação com taxa de contraste (1,6:1)”

  Na página Turismo a animação com os textos grandes “Cultura local”, “Natureza”, “Aventura” e “Roteiros”, apresentam problemas de contraste com a combinação de cores #DDDCDB (cor de primeiro plano) e #F0EFED(cor de plano de fundo) (Figura 3)

  

  Figura 3- Animação com texto grande não passa na avaliação de contraste (1:1)”

  Recomendações
  Recomendamos a revisão das cores das páginas para garantir os valores mínimos de contraste do texto grande, principalmente nos pares de cores indicados.

  • Caso exista texto grande com pouco contraste, em que as cores utilizadas sejam as mesmas do logótipo da entidade, recomendamos a substituição dessas cores por outras que garantam um contraste mínimo de 3:1. Por exemplo, podem ser usados tons semelhantes ao do logotipo ou outras cores da identidade gráfica da marca.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #37 A reprodução dos leitores de multimédia inicia automaticamente

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 7.1

  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

  Notas Gerais

  • Os leitores de multimédia devem apenas iniciar a reprodução do seu conteúdo quando o utilizador pressiona o comando “Play”.

  No website da Câmara Municipal de Oliveira do Hospital, verificou‑se que o vídeo apresentado na secção “Venha e descubra Oliveira do Hospital” não disponibiliza controlos acessíveis de reprodução (pausar, ativar legendas...). O utilizador não consegue pausar o vídeo, ativar legendas ou interagir com outros comandos, tanto com o rato como com o teclado. (Figura 1)

  

  Figura 1- Vídeo sem botões etiquetados

  Este vídeo destaque específico impede a operação e o controlo adequados, comprometendo o cumprimento do requisito.
  Outros conteúdos multimédia do site apresentam controlos funcionais, por exemplo com possibilidade de selecionar "Controlo deslizante de volume" (Figura 2)

  

  Figura 2- Há vídeos com botões corretamente etiquetados

  Recomendações de melhorias

  • Garantir que em todos os vídeos os botões sejam lidos pelos leitores de ecrã e que os seus botões sejam operáveis através do rato e do teclado. O requisito também se aplica caso o leitor de multimédia seja externo (ex: Youtube, Vimeo…) assegurando que nenhum elemento gráfico impede o foco ou a interação.
  • Adicionar um texto alternativo em português aos controlos dos botões para serem lidos pelo leitor de ecrã.
  • Deve ser removida qualquer configuração que oculte controlos nativos do player e assegurada a compatibilidade com tecnologias de apoio.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #38 As legendas fornecidas pelos vídeos são automáticas ou estão em inglês

  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

  Notas Gerais

  • 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.
  • As legendas dos conteúdos multimédia devem estar no mesmo idioma do site, para que os utilizadores consigam aceder ao conteúdo na língua que escolheram, principalmente quando não sabem a outra língua.

  Na página inicial a secção "Visite Oliveira do Hospital" apresenta três vídeos os quais identificamos que é possível ligar e desligar a legenda dos vídeos, no entanto, a legenda fornecida é automática, sendo necessário inserir uma legenda fechada para o vídeo. Além disso, o segundo vídeo apresenta linguagem gestual cortada (Figura 1)

  

  Figura 1- Vídeos com legendas automáticas

  A legenda é diferente do idioma do site

  O primeiro vídeo da secção "Visite Oliveira do Hospital" apresenta uma legenda, mas está numa língua diferente da do site, pelo que pode não ser compreendido pelos utilizadores que não são fluentes nessa língua. (Figura 2)

  

  Figura 2- Vídeo com legenda em inglês

  Recomendação de melhoria
  Recomendamos que seja incluído uma legenda fechada para cada vídeo, que seja adicionada uma transcrição da narração em português junto do vídeo.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #24 Há elementos HTML com CSS aplicado que não alinham à esquerda

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 8.1

  Quando se retira a CSS, todos os elementos HTML devem alinhar à esquerda.
  – ver requisito 8.1 na lista 10 aspetos

  Notas Gerais

  • Quando se desativam todos os estilos visuais, o conteúdo da página é apresentado alinhado à esquerda e apresenta-se de forma linear.

  Ao desativar os estilos CSS do website, verifica-se que alguns elementos não se apresentam alinhados à esquerda, como por exemplo as opções de segundo nível do menu principal surgindo com indentação ou posicionamento irregular. (Figura 1)

  

  Figura 1- Opções de segundo nível do menu não se alinham à esquerda

  Em particular, o menu principal e as respetivas subopções aparecem deslocados, e são também exibidos ícones isolados que originalmente não fazem parte da interface visual, mas que surgem sem contexto quando os estilos são removidos. (Figura 2)

  

  Figura 2- Ícone de menu visível ao retirar CSS mas não se apresenta no website

  Esta situação indica que parte da organização visual dos elementos depende do CSS para definir o seu posicionamento, em vez de resultar da estrutura natural do HTML. Como consequência, o conteúdo não é apresentado de forma totalmente linear quando os estilos são desativados, o que compromete a conformidade com o presente requisito.

  Recomendação de melhoria


  Reestruturar o HTML de forma a garantir que o conteúdo segue uma organização lógica e linear independentemente da aplicação de estilos. Elementos de navegação devem ser estruturados com listas semânticas (<ul>, <li>), e os ícones decorativos devem ser corretamente associados aos seus elementos ou ocultados quando não acrescentam informação relevante. O CSS deverá ser utilizado apenas para melhorar a apresentação visual, e não para corrigir ou compensar problemas estruturais do HTML.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #25 Quando se retira a CSS, a informação não aparece numa ordem lógica

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 8.2

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

  Notas Gerais

  • Tendo em conta que o posicionamento de elementos no código pode não refletir a ordem visual de leitura, deve ser assegurada a ordem correta do conteúdo quando se desativam os estilos visuais.

  Ao desativar os estilos, são exibidos vários campos e blocos de formulário que não fazem parte da interface visível, o que indica a existência de elementos duplicados ou obsoletos presentes no DOM e ocultados apenas por CSS.

  Após a remoção do CSS, a informação do website mantém alguma legibilidade, mas a sequência dos conteúdos apresenta inconsistências. Observamos que a ordem de leitura não é totalmente clara nem otimizada quando os estilos são removidos.

  Na página Documentação online | Transparência Municipal aparecem campos dos formulários que não são visíveis no website. (Figura 1)

  

  Figura 1- Campos de formulários que não são visíveis na interface, aparecem visíveis quando se retira o CSS

  Recomendação de melhoria


  Garantir que a estrutura do HTML reflete corretamente a hierarquia e a ordem lógica da informação, independentemente da apresentação visual. O conteúdo deve seguir uma sequência semântica clara, utilizando corretamente elementos estruturais como cabeçalhos (<h1>–<h6>), listas (<ul>, <ol>), secções (<section>, <nav>, <main>) e agrupamentos apropriados de navegação. A ordem dos elementos no código deve corresponder à ordem natural de leitura da página, evitando depender do CSS para reposicionar ou reorganizar conteúdos. Isto permitirá que a página mantenha uma leitura coerente mesmo quando os estilos visuais não estão disponíveis.

  As subopções do menu não estão estruturadas como lista integradas nas opções de 1º nível

  As subopções do menu não estão estruturadas como uma lista hierarquicamente integrada com as opções de primeiro nível. A organização atual assenta em múltiplos div independentes, associados posteriormente a um cabeçalho e a um segundo bloco de navegação (<nav>), originando listas separadas e desconectadas do conjunto principal da navegação. (Figura 2)

  

  Figura 2- Menu principal não está estruturado em uma ordem lógica em sua semântica e apresenta opções de primeiro e segundo nível separados ao retirar CSS

  Quando os estilos visuais (CSS) são desativados, verifica‑se que a ordem de leitura e a relação semântica entre itens de primeiro nível e respetivas subopções não são preservadas. As subopções surgem afastadas do menu principal, evidenciando que não estão corretamente aninhadas na estrutura do HTML. Esta falha viola o presente requisito, uma vez que a hierarquia lógica não é refletida no código.

  Recomendações de melhorias

  Deve-se estruturar devidamente as opções e sub-opções de menu com elementos de lista e ARIA como referido no Requisito 1.1 e o Requisito 1.2 da lista 10 aspetos.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #29 R 8.3- 10 Aspetos - Menu de acessibilidade estruturado incorretamente

  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

  Uso inadequado de links em vez de botões no menu de acessibilidade

  Na página inicial o website integra uma barra flutuante de “Accessibility Tools” (plugin Pojo A11y) destinada a disponibilizar funcionalidades de apoio à acessibilidade. Contudo, a sua implementação apresenta alguns problemas estruturais e semânticos que podem comprometer a experiência de utilizadores que recorrem a tecnologias de apoio. (Figura 1)

  

  Figura 1 - Menu "Accessibility Tools" com estrutura incorreta

  Os controlos da barra são implementados com elementos aos quais é atribuído role="button", apesar de não realizarem navegação, mas sim ações como aumentar texto ou alterar contraste. Esta abordagem pode gerar comportamentos inesperados (como o salto para o topo da página) e nem sempre é corretamente interpretada por leitores de ecrã, contrariando boas práticas de semântica HTML.

  Adicionalmente, o componente é estruturado com um elemento

• evidência: issue #28 Existem elementos com a semântica 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

  Notas Gerais

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

  Botões que estão estruturados incorretamente com tags genéricas como <div> e <span>

  As páginas História e Relatórios de Sustentabilidade apresentam os botões "Diminuir", "Aumentar" e “Documentos Online” com uma implementação incorreta, uma vez que estão estruturados como um elemento <div> estilizados para parecer um botão, mas funcionam semanticamente como links. (Figura 1 e 2)

  

  Figura 1 - Botões “Diminuir -” e “Aumentar +” com semântica incorreta e atributo <div>.

  

  Figura 2 - Botão “Documentos Online” estruturado como <div>.

  Esta abordagem compromete a semântica, a navegação por teclado e a interpretação por leitores de ecrã.

  Recomendação de melhoria

  • É necessário a revisão de todo o website, elementos HTML adequados para representar a função e o tipo de conteúdo.
  • Alterar botões que estão estruturados como <div>, quando na verdade são um atributo <button>.
  • Usar aria-expanded, aria-label dinâmico para utilizadores terem feedback de comportamentos previsíveis.
  • Corrigir o botão “Documentos Online” substituindo o <div> por um elemento semântico apropriado, como um <a> (para navegação) ou <button> (para ações), garantindo foco por teclado e correta identificação pelas tecnologias assistivas.

  Sempre que os botões forem elementos de navegação recomenda-se informar explicitamente que a navegação ocorrerá em nova janela/aba, utilizando práticas acessíveis tais como:

  • Adicionar a indicação textual “(abre em nova janela)” no próprio link, por exemplo usar aria-label descritivo (ex.: “Boletim Municipal – abre em nova janela”)
  • Assegurar que os ícones continuem marcados como decorativos (aria-hidden="true").

  Slideshow sem estrutura semântica e controlo de animação

  O website utiliza um slideshow automático construído apenas com contêineres <div> e imagens aplicadas como background-image, sem qualquer estrutura semântica que identifique o componente como um carrossel. (Figura 2)

  

  Figura 3 - Animação com controlos automáticos e estruturado com <div>.

  Além disso, o elemento não disponibiliza mecanismos de pausa, avanço ou retrocesso, impossibilitando o controlo da animação por parte dos utilizadores, especialmente quem utiliza tecnologias de apoio ou navega por teclado.

  Além disso, os textos alternativos associados às imagens não descrevem adequadamente os respetivos conteúdos por exemplo aria-label="1 / 3". As imagens funcionam como elementos promocionais ou ilustrativos do Município, como na página Rotas, mas os textos alternativos não refletem essa função, deixando de transmitir informação relevante a utilizadores das tecnologias de apoio. (ver Requisito 5.1)

  Outros exemplos de páginas que acontecem a mesma problemática:

  https://www.cm-oliveiradohospital.pt/municipio/demografia/
  https://www.cm-oliveiradohospital.pt/freguesias/avo/
  https://www.cm-oliveiradohospital.pt/turismo/alojamento/
  https://www.cm-oliveiradohospital.pt/servicos/educacao/

  Recomendação de melhoria

  Recomendamos substituir o slideshow atual por um carrossel acessível, estruturado com semântica adequada e controlos visíveis e operáveis por teclado. O componente deve incluir mecanismos de pausa da animação , botões de navegação, identificação acessível e textos alternativos significativos para cada imagem. A estrutura deve apresentar ordem lógica e equivalência informativa entre a experiência visual e a disponibilizada às tecnologias de apoio, garantindo assim uma navegação inclusiva para todos os utilizadores.


  Para mais informações é possível consultar os artigos Carousel Structure e Carousel (Slide Show or Image Rotator) Pattern do W3C. Com elementos ARIA, utilizar o padrão W3C ARIA Carousel

  Tabela estruturada como grid

  A página Calendário das Sessões Ordinárias apresenta uma componente de calendário visualmente estruturada como uma tabela, mas foi implementado utilizando div com role="grid" e papéis ARIA como row, columnheader e gridcell, caracterizando-o como um ARIA Grid. (Figura 4)

  

  Figura 4 - Calendário das Sessões ordinárias estruturado como ARIA Grid, quando cumpre a função de uma tabela simples.

  No entanto, trata-se de um conteúdo meramente informativo e com dados estáticos, estruturado em duas colunas (Mês x Dias), sem funcionalidades avançadas como navegação por setas, edição de células, ordenação dinâmica ou seleção interativa, comportamentos esperados em um padrão grid.

  Do ponto de vista de acessibilidade e semântica HTML, essa abordagem gera uma complexidade desnecessária e pode impactar negativamente a experiência dos utilizadores com tecnologias assistivas. Como o conteúdo é essencialmente tabular e estático, a solução semanticamente adequada é a utilização do elemento nativo <table>, com estrutura composta por <thead>, <tbody>, <th> e <td>. Tabelas HTML já possuem suporte nativo para associação de cabeçalhos, navegação assistiva e interpretação correta por leitores de ecrã, eliminando a necessidade de ARIA adicional.

  Recomendações de Melhoria
  Recomendamos substituir a estrutura atual baseada em div e role="grid" por uma tabela HTML semântica. Essa alteração simplifica a implementação, melhora a robustez do código e garante melhor conformidade com boas práticas de acessibilidade.

• evidência: issue #27 Existem listas com a semântica 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

  Carrossel não está estruturado como lista

  Os componentes presentes nas páginas devem estar corretamente estruturados para garantir a correta leitura e funcionamento.  Ao remover a folha de estilo da homepage, é possível identificar que o elemento apresentado não está semanticamente correto, os seus elementos não se encontram de uma forma estruturada. Ao invés de <div> é necessário que seja uma lista. (Figura 1)

  

  Figura 1 – Carrossel de notícias estruturado como <div>  


  A ausência de uma estrutura de lista no carrossel compromete a experiência de utilizadores de leitores de ecrã, que deixam de receber a informação de forma sequencial e relacionadas com o conteúdo. Por exemplo ao navegar pelo carrossel de Notícias com o leitor de ecrã NVDA, foram exibidas opções de uma notícia anterior não visíveis ou apresentadas visualmente em seu estado atual.

  

  Figura 2 – Leitor de ecrã NVDA sequência desordenada do carrossel 

  O mesmo acontece na página Hillstar Eventos, com um carrossel estruturado como <div>. Mas além disso o carrossel apresenta um problema semântico grave porque os seus elementos essenciais (imagens, numeração e controlos) estão separados em múltiplas <div> sem qualquer ligação estrutural significativa. (Figura 3)

  

  Figura 3 – Leitor de ecrã NVDA sequência desordenada do carrossel 

  A ausência de elementos semânticos adequados (como <button>, <figure>, role ARIA e agrupamentos lógicos) impede que tecnologias de apoio reconheçam o carrossel como um único componente navegável. Como resultado, utilizadores de leitores de ecrã ou navegação por teclado não conseguem compreender a relação entre o slide apresentado, a numeração e os controlos, prejudicando a acessibilidade, a perceção e a usabilidade.

  Recomendação 
  Recomendamos a revisão do website para a estrutura semântica do componente carrossel para garantir o correto funcionamento do mesmo. Para mais informações é possível consultar boas práticas para a implementação do elemento carrossel no código na página Carousel Structure da W3C.

  Paginação não é uma lista

  A paginação das Notícias apresenta limitações ao nível da semântica estrutural e da experiência de utilizadores que recorrem a tecnologias de apoio. (Figura 4)

  

  Figura 4 – Paginação não é anunciada pelos leitores de ecrã corretamente 

  Embora utilize corretamente elementos <a> para navegação e inclua o atributo aria-current="page" na página ativa, a estrutura atual não está inserida numa landmark de navegação <nav> nem possui um rótulo acessível que identifique claramente o seu propósito. Esta ausência dificulta a navegação por regiões para utilizadores de leitores de ecrã.

  Adicionalmente, os links são compostos apenas por números (“1”, “2”, “4”, etc.), sem contexto adicional. Quando anunciados por um leitor de ecrã, são lidos apenas como “link 4”, não transmitindo que se trata de uma ligação para uma determinada página de resultados. O elemento de reticências (“…”) também não se encontra oculto das tecnologias de apoio, podendo ser anunciado sem acrescentar significado funcional.

  Verifica-se ainda a ausência de marcação semântica em lista (<ul><li>), recomendada para conjuntos de itens relacionados como paginações. Esta melhoria reforça a estrutura lógica do conteúdo e facilita a interpretação por tecnologias assistivas.

  Listas que não estão marcadas corretamente

  Na página Recrutamento de Juízes Sociais há elementos textuais que visualmente estruturados como listas mas semanticamente não estão marcados como tal. (Figura 5) O mesmo acontece na página Instrumentos de Gestão Territorial (PDM e PP) e Regeneração Urbana.

  

  Figura 5 – Textos visualmente estruturados como lista, mas semanticamente marcados com <p>

  Recomendações gerais

  Recomenda-se:

  • Corrigir elementos e identificá-los como listas
  • Estruturar a paginação como lista semântica (<ul><li>);
  • Envolver a paginação num elemento
  • Adicionar aria-label aos links numéricos (ex.: “Ir para a página 4”);
  • Manter aria-current="page" na página ativa, com descrição contextualizada;

• evidência: issue #26 Existem acordeões estruturados incorretamente

  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

  Notas Gerais

  • Um acordeão é um conjunto de cabeçalhos interativos empilhados verticalmente, cada um contendo um título e uma secção do conteúdo. Os títulos funcionam como controlos que permitem aos utilizadores revelar ou ocultar as secções de conteúdo associadas. Os acordeões são normalmente utilizados para reduzir a necessidade de deslocação ao apresentar várias secções de conteúdo numa única página.

  Acordeões estruturados como divs

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

  Na página Documentação online | Transparência Municipal Os acordeões dos formulários “Sugestões”, “Reclamações” e “Dúvidas” apresentados não são acessíveis, pois utilizam <div> como controlo para abrir e fechar. (Figura 1)

  

  Figura 1 - Acordeão estruturado como <div>

  Sendo assim, o conteúdo não é focável por teclado nem comunica o seu estado (expandido ou recolhido) às tecnologias de apoio. O comportamento do componente é controlado apenas por estilização visual (por exemplo, através de display: none), sem recurso a elementos semânticos adequados descrevam a sua função e estado.

  Como consequência, utilizadores que navegam exclusivamente por teclado ou que recorrem a leitores de ecrã não conseguem interagir corretamente com o componente, nem perceber quando o conteúdo está visível ou oculto, ou se o elemento está aberto ou fechado quando tem o foco do teclado.

  Recomendação de melhoria

  Recomendamos a revisão do site e consequente correção, de modo a garantir a leitura correta por parte das tecnologias de apoio. Algumas soluções poderiam ser:

  • Usar as tags HTML <button> e <a> para definir elementos como clicáveis. O <button> deve ser utilizado para interações dentro da página onde o utilizador se encontra e <a> para interações que levam o utilizador para uma nova página.
  • Preencher o atributo href=”” nos links com o endereço de destino. Se não houver endereço, recomendamos retirar o elemento e deixar só como texto.
  • Em acordeões, usar links com cabeçalhos para os títulos clicáveis. Os cabeçalhos devem começar no nível seguinte ao do título anterior <h2> a <h6>.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #33 O foco não está limitado na modal das imagens

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

  Modais de imagens (NOK)

  A modal da imagem na página Orçamento Participativo Jovem quando está aberta, não mantém o foco do teclado restrito ao seu conteúdo, sendo assim é possível navegar com as teclas direcionais e aceder conteúdos por trás da janela. (Figura 1)

  

  Figura 1 - Modal da pesquisa com foco restrito a caixa de diálogo

  Esta inconsistência quebra a hierarquia da informação da interface, permitindo a interação com componentes que deveriam estar temporariamente inacessíveis. Além disso a imagem não possui texto alternativo correto, que descreva em síntese o seu conteúdo (Requisito 5.1 Checklist - 10 aspetos). Quando a modal é aberta esse texto alternativo é anunciado "cartaz-OPJ2022" e pode confundir utilizadores sobre o seu objetivo.

  Recomendações de melhoria
  É necessário restringir a navegação por teclado (Tab/Shift+Tab) a área da modal, impedindo que o foco saia de seus elementos e permaneça exclusivamente nos elementos que a constituem enquanto estiver ativa.

  Modais (OK)

  As modais de Cookies, Login e de pesquisa estão a cumprir corretamente o requisito. Recomendamos considerá-las como cases de sucesso, e apliquem ao restante das modais no website. (Figura 2)

  

  Figura 2 - Modal da pesquisa com foco restrito a caixa de diálogo

  Como demonstra a modal de pesquisa mantém o foco restrito ao conteúdo da modal. Permitindo utilizadores selecionar apenas elementos interativos da modal, caso optem por sair da modal podem utilizar o botão de “Fechar” 


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

Lista de evidências recolhidas:

• evidência: issue #34 O botão 'Fechar’ está em outro idioma

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

  As modais devem apresentar um botão de fechar nomeado de forma clara e no mesmo idioma do website.

  Os botões de ‘Fechar’ das modais e do menu estão em inglês. Apesar de existir um botão de fechar, o mesmo encontra-se em inglês e não funciona com o ESC, apenas com o enter e o rato. (Figura 1)

  

  Figura 1 - Modal de Cookies com texto alternativo em inglês e botão "Fechar" só funciona com tecla ENTER

  Já o botão fechar das modais de "Login" e "Pesquisa" funcionam corretamente, no entanto seu texto alternativo está em inglês, com aria-label="Close". (Figura 2)

  

  Figura 2 - Modal de Pesquisa com texto alternativo em inglês

  Recomendação
  Recomendamos reverem as modais e o menu do website para garantir que os botões de abrir e fechar estejam rotulados no mesmo idioma do website. E o funcionamento da modal de cookies, para que a tecla ESC também resulte na interação de fechar a modal.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #39 Não existe um resumo do propósito do website

  etiqueta: chk conteúdoetiqueta: NOKetiqueta: R 1.1

  O sítio Web apresenta um resumo breve do seu propósito, visível sem fazer scroll.
  – ver requisito 1.1 na lista Conteúdo

  Notas gerais

  • Num primeiro vislumbre do sítio Web deve ser visível uma breve definição do seu propósito que dê a indicação ao utilizador de que sítio Web se trata e quais são as tarefas que se podem levar a efeito.

  O propósito do website difere da missão ou do objetivo da entidade. O propósito deve transmitir, de forma clara, o que o utilizador pode efetivamente encontrar e realizar no website. Esse propósito deve ser imediatamente visível na página, sem ser necessário fazer scroll, avançar no carrossel, entre outros.

  Durante a análise verificou‑se que o Município de Oliveira do Hospital não apresenta um resumo claro do propósito da plataforma. Em vez disso, o conteúdo inicial consiste exclusivamente num carrossel com mensagens de caráter promocional de eventos e atividades em destaque (Figura 1).

  

  A ausência de uma descrição introdutória compromete a compreensão imediata da funcionalidade e objetivo do website, especialmente para utilizadores que necessitam de referências textuais diretas para orientar a navegação e saber de imediato quais serviços e principais objetivos das navegações do website.

  Recomendação
  Deve ser adicionado um resumo do propósito. Como referência de uma boa prática, é possível verificar no website acessibilidade.gov que o seu propósito está escrito no topo da página.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #40 Não existe um glossário e há termos complexos sem definição

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

  Os termos mais complexos têm uma definição agregada.
  – ver requisito 1.2 na lista Conteúdo

  Notas gerais

  • Em sites com termos técnicos ou complexos, que sejam difíceis de compreender, deve existir uma página de glossário com as definições dessas palavras. O glossário deve apresentar a definição dos termos e conceitos de forma clara e breve, para que seja facilmente compreensível pelos utilizadores.
  • Os glossários devem estar, preferencialmente, inseridos numa página HTML dentro do site. Assim, caso seja feita referência a algum termo complexo noutras páginas do site, deve-se colocar uma hiperligação para a página do glossário. Em alternativa, o glossário pode ser apresentado num ficheiro PDF desde que seja garantida a sua acessibilidade.

  Ausência de glossário no website
  Não foi encontrado um glossário no website do Município de Oliveira do Hospital , apesar de observarmos que há conteúdos que existem siglas com definições agregadas. Existem também muitas outras páginas com siglas sem os seus respetivos significados.

  Por exemplo, a página Ação Social Escolar 2025/2026 – Pré-Escolar e 1.º Ciclo do Ensino Básico possui termos complexos sem significado agregado. Por exemplo, AAAF, CEB, CAF e AECH (Figura 1)

  

  Figura 1 - Página com siglas sem definições agregadas no decorrer do conteúdo

  Outras páginas com siglas sem significados agregados:

  • https://www.cm-oliveiradohospital.pt/camara-municipal-aprova-orcamento-municipal-superior-a-50-milhoes-de-euros/
  • https://www.cm-oliveiradohospital.pt/municipio-avanca-em-2026-com-projeto-de-75-milhoes-para-reconversao-de-area-de-acolhimento-empresarial/
  • https://www.cm-oliveiradohospital.pt/oliveira-do-hospital-renova-galardao-ecoxxi-com-a-melhor-pontuacao-de-sempre/

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #43 O corpo de texto não possui tamanho mínimo recomendado

  etiqueta: chk conteúdoetiqueta: NOKetiqueta: R 2.1

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

  Notas Gerais

  • Para garantir a legibilidade do corpo de texto, este deve ter um tamanho igual ou superior a 12pt, que equivale a 16px.Para garantir a legibilidade do corpo de texto, este deve ter um tamanho igual ou superior a 12pt, que equivale a 16px.

  A página Orquestra apresenta um parágrafo com informação primária com 14px tamanho inferior ao recomendado. (Figura 1)

  

  Figura 1 - Corpo de texto da página "Orquestra" com 14px

  O breadcrumb em todo o website Município de Oliveira do Hospital é considerado uma informação primária do corpo de texto, e possui tamanho inferior a 12pontos(16px) por exemplo nos textos do breadcrumb: “Início”, “Turismo”, “Patrimônio classificado”, “Interesse Nacional (IIN) e “Capela Ferreiros” (Figura 1)

  

  Figura 2 - Demonstração do breadcrumb na página Capela dos Ferreiros

  Assim como na página Instrumentos de Gestão Territorial (PDM e PP) e Regeneração Urbana a secção “ZEP – Zona Especial de Proteção – Capela dos Ferreiros” apresenta um parágrafo com 13px, tamanho inferior ao recomendado. (Figura 3)

  

  Figura 3 - Corpo de texto da página com 13px

  Além disso, existem tabelas incorporadas em páginas no corpo de texto e seu título com 11.7px é um tamanho inferior ao recomendado.

  Exemplo de páginas:

  • https://www.cm-oliveiradohospital.pt/servicos/educacao/refeicoes-escolares/
  • https://www.cm-oliveiradohospital.pt/servicos/educacao/atividades-de-verao/
  • https://www.cm-oliveiradohospital.pt/informacoes/elementor-31478/

  Recomendação de melhoria

  • Rever o website para corrigir corpo de texto e garantir um tamanho igual ou superior ao recomendado.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #44 A informação secundárias tem um tamanho de letra inferior ao recomendado

  etiqueta: chk conteúdoetiqueta: NOKetiqueta: R 2.2

  A informação secundária (datas, autores) utiliza, no mínimo, um tamanho de letra de 10 pontos.
  – ver requisito 2.2 na lista Conteúdo

  Notas Gerais

  • A informação secundária, como os autores de textos ou de imagens, as datas de publicação ou outros tipos de meta-informação, podem usar tamanhos de letra mais pequenos, mas, no mínimo, com 10 pontos, assegurando sempre que os mesmos são escaláveis para tamanhos superiores, sempre que o utilizador considere necessário.

  No rodapé do website foram identificadas informações secundárias apresentadas com um tamanho de letra inferior ao mínimo recomendado. Em particular, os textos associados aos campos obrigatórios “(*) Chamada para rede fixa nacional” e “(**) Chamada para rede móvel nacional” encontram‑se com um tamanho de 8.92px, valor abaixo dos 10 pontos (equivalente a 13px), exigidos pelo presente critério. (Figura 1)

  

  Figura 1 - Informações secundárias do rodapé com tamanho inferior ao recomendado

  Esta dimensão reduzida compromete a legibilidade e cria barreiras para utilizadores com baixa visão ou que necessitem de ampliar o conteúdo.

  O mesmo acontece na página https://www.cm-oliveiradohospital.pt/instrumentos-de-gestao-territorial-pdm-e-pp-e-regeneracao-urbana/ com o texto “in Regime Jurídico dos Instrumentos de Gestão Territorial (RJIGT)” no tamanho de 10px, não cumpre o valor mínimo para informação secundária. (Figura 2)

  

  Figura 2 - Informações secundárias no corpo de texto com tamanho inferior ao recomendado

  Outras páginas que precisam de correção:

  • https://www.cm-oliveiradohospital.pt/informacoes/oigp-serra-da-estrela-sul/
  • https://www.cm-oliveiradohospital.pt/municipio/orgaos-autarquicos/assembleia-municipal/regimento/
  • https://www.cm-oliveiradohospital.pt/municipio/documentos-online/
  • https://www.cm-oliveiradohospital.pt/municipio/orgaos-autarquicos/camara-municipal/distribuicao-de-pelouros/

  Recomendação de melhoria

  Recomendamos revisar todo website, e aumentar o tamanho de letra das informações secundárias para, no mínimo 10 pontos(13px). Garantindo simultaneamente que a fonte permanece escalável, permitindo ampliação por tecnologias assistivas ou pelo zoom do navegador;

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #45 Existem blocos de textos com mais de 100 caracteres por linha

  etiqueta: chk conteúdoetiqueta: NOKetiqueta: R 2.3

  Blocos e linhas de texto com largura não superior a 100 caracteres.
  – ver requisito 2.3 na lista Conteúdo

  Notas Gerais

  • Para assegurar uma boa leitura, as linhas de texto devem ter até 80 caracteres (incluindo espaços). No limite, podem ir até aos 100 caracteres (incluindo espaços).

  Os blocos de texto da página Cidade de Oliveira do Hospital possuem 114 caracteres por linha, valor superior ao recomendado. (Figura 1)

  

  Figura 1 - Análise de bloco de texto com ferramenta WordCounter

  Exemplos de outras páginas com a mesma problemática:

  • https://www.cm-oliveiradohospital.pt/servicos/gabinete-de-apoio-ao-emigrante-gae/
  • https://www.cm-oliveiradohospital.pt/servicos/contratacao-publica/
  • https://www.cm-oliveiradohospital.pt/servicos/igualdade-local-cidadania-responsavel/
  • https://www.cm-oliveiradohospital.pt/freguesias/ervedal-da-beira/

  Recomendação

  Revisar blocos de textos para garantir que não é ultrapassado o número máximo de caracteres por linha. Rcomendamos que seja definida uma largura máxima para as caixas de texto (max-width, em CSS), com unidades relativas ao tamanho de fonte (unidades em ou rem).

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #47 O menu ultrapassa 9 opções no segundo nível

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

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

  Notas Gerais

  • As boas práticas(https://www.nngroup.com/videos/number-items-navigation-menu/) 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.

  Na opção "Serviços" do menu principal é possível observar que existem 15 opções, o que significa que está acima do número de opções recomendado. (Figura 1)

  

  Figura 1 - Menu principal com mais de 9 opções

  Além disso, o menu secundário apresenta 16 opções e um encadeamento extenso de itens de segundo nível e respetivas subopções, o que dificulta a perceção da estrutura e gera confusão na compreensão das informações. Por exemplo na página Percurso Pedestre (Figura 2)

  

  Figura 2- Menu secundário de páginas interiores com mais de 9 opções

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

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #48 Menu desaparece nas versões para dispositivos móveis

  etiqueta: chk conteúdoetiqueta: NOKetiqueta: R 3.2

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

  Notas gerais:

  • As opções de primeiro nível da navegação principal estão sempre visíveis e encontram-se sempre no mesmo local em todas as páginas. A posição atual do utilizador na estrutura de navegação deve ser evidenciada.

  Independentemente do breakpoint, deve sempre existir um menu de navegação visível. Observamos que nas versões para dispositivos móveis, o menu de navegação desaparece das páginas, sendo assim não é possível aceder as opções do menu principal o que impede o utilizador de navegar livremente pelo website. (Figura 1)

  

  Figura 1 - Página inicial com menu indisponível nas versões para dispositivos móveis

  O mesmo acontece com o menu secundário, que desaparece nas versões para dispositivos móveis, mas está disponível nas versão desktop (Figura 2 e 3)

  

  Figura 2 - Página de Notícias com menu secundário indisponível nas versões para dispositivos móveis

  

  Figura 3 - Menu secundário disponível apenas na versão desktop

  Recomendação de melhoria
  Deve ser garantido que o menu de navegação está presente em todas as páginas, independentemente do breakpoint em questão.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #49 As hiperligações não se diferenciam do texto envolvente

  etiqueta: chk conteúdoetiqueta: NOKetiqueta: R 3.3

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

  Notas Gerais

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

  Existem páginas em que as hiperligações não têm diferenciação suficiente do texto envolvente. Por exemplo, as hiperligações do breadcrumb não estão sublinhadas e podem ser confundidas com texto comum, pois só é perceptível como clicáveis quando o cursor é alterado. (Figura 1)

  

  Figura 1 - Breadcrumb não é perceptível como uma hiperligação

  Na página da Declaração de Acessibilidade as hiperligações das Checklists "10 Aspectos funcionais”, “Conteúdo” e “ Transação” não aparentam ser clicáveis e não se diferenciam do texto envolvente. (Figura 2)

  

  Figura 2 - Breadcrumb não é perceptível como uma hiperligação

  As hiperligações em texto devem apresentar-se da mesma forma em todo o sítio Web. Na página inicial a secção “Avisos” o conteúdo da notícia “Informações sobre transportes publicos” não apresenta-se visualmente como link mas possui um href atribuído. (Figura 3)

  

  Figura 3 - Avisos da página inicial com hiperligações não identificadas com sublinhado

  A página Recrutamento de Técnicos de Apoio Informático – Eleições para o Parlamento Europeu 2024 possui hiperligações que não se diferenciam do texto envolvente. (Figura 4)

  

  Figura 4 - Links que direcionam para páginas externas não identificados como hiperligações no corpo de texto

  Outras páginas com o mesmo problema:

  • https://www.cm-oliveiradohospital.pt/acao-social-escolar-2025-2026-pre-escolar-e-1-o-ciclo-do-ensino-basico/
  • https://www.cm-oliveiradohospital.pt/instrumentos-de-gestao-territorial-pdm-e-pp-e-regeneracao-urbana/
  • https://www.cm-oliveiradohospital.pt/camara-municipal-de-oliveira-do-hospital-lanca-orcamento-participativo-jovem/
  • https://www.cm-oliveiradohospital.pt/orcamento-participativo-jovem-2022-apresentacao-de-propostas-ate-final-de-setembro/

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

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #50 Os documentos longos não têm um índice no topo

  etiqueta: chk conteúdoetiqueta: NOKetiqueta: R 4.1

  Os documentos longos têm um índice no topo com hiperligações internas para o mesmo.
  – ver requisito 4.1 na lista Conteúdo

  Notas gerais:

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

  Nas páginas consideradas longas, como a página Instrumentos de Gestão Territorial (PDM e PP) e Regeneração Urbana, não existem um índice com hiperligações para cada secção interna dessa página. (Figura 1)

  

  Figura 1 - Página longa sem índice no topo

  Outros exemplos de páginas longas sem índice no topo:

  • Complexo Municipal de Piscinas e Campos de Ténis https://www.cm-oliveiradohospital.pt/servicos/desporto/equipamentos-desportivos/complexo-municipal-de-piscinas-e-campos-de-tenis/
  • Câmara Municipal congratula as 40 empresas PME Líder 2024 de Oliveira do Hospital https://www.cm-oliveiradohospital.pt/camara-municipal-congratula-as-40-empresas-pme-lider-2024-de-oliveira-do-hospital/

  Recomendações
  Adicionar um índice com hiperligações e garantir que o índice tem hiperligações que remetem para cada secção interna.

  O índice está a ser substituído por acordeões que não estão estruturados corretamente

  Notas gerais:

  • O uso de acordeões como substituição de um índice é uma solução válida, mas é importante ter em consideração alguns aspetos essenciais para garantir a acessibilidade. A estrutura do acordeão deve ser construída de forma adequada, assegurando que funcione sem problemas para todos os utilizadores, incluindo aqueles que utilizam tecnologias de apoio.

  Nas páginas Gabinete de Apoio Ao Emigrante (GAE) e Documentação online | Transparência Municipal , foram identificados acordeões cuja estrutura não está corretamente implementada. Embora reduzam o comprimento das páginas, estes componentes não são acessíveis para todos os utilizadores, comprometendo a navegação e a compreensão da informação. Por este motivo, devem ser corrigidos

  

  Figura 1- Acordeão "Sobre o GAE" com problemas de acessibilidade com leitores de ecrã e por teclado

  

  Figura 2- Acordeões disponíveis não possuem controlos acessíveis

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

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #51 O layout do sítio Web não é adaptável a plataformas móveis

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

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

  Notas Gerais

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

  A página Instrumentos de Gestão Territorial (PDM e PP) e Regeneração Urbana revela que os elementos interativos “Boletim Municipal”, “Serviços do Munícipe” “Documentos Online” e breadcrumbs, não se adaptam a diferentes resoluções de ecrã. Apresentando seus contornos e textos cortados no ecrã de dispositivos móveis.

  

  Na versão para dispositivos móveis, verifica‑se que a imagem de destaque da página Documentos Online não se ajusta corretamente ao espaço destinado ao banner, ficando desproporcional ao layout. Além disso, os botões “Boletim Municipal”, “Serviços do Munícipe” e “Documentos Online” deixam de ser exibidos no ecrã, comprometendo a navegação e a experiência do utilizadores.

  

  Recomendações
  Garantir que todo o layout o website, possui comportamento responsivo e adapta-se às diferentes resoluções de ecrã, sem necessidade de fazer varrimento horizontal.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #52 Existem elementos interativos que são acionados apenas com a passagem do rato

  etiqueta: chk conteúdoetiqueta: NOKetiqueta: R 5.1

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

  O site não deve conter elementos interativos (hiperligações, botões, submenu) que são apenas acionados quando se passa por cima com o rato. Esta interação impede que os elementos sejam acessíveis em ecrãs tácteis e dificulta a navegação com tecnologias de apoio.

  Existem elementos interativos, por exemplo as opções de segundo nível do menu principal que apenas são acionados quando se passa o rato por cima (hover). (Figura 1)

  

  Figura 1 - Menu principal na opção "Freguesia" apenas acionado através do hover

  Esta interação impede que os elementos sejam acessíveis em ecrãs tácteis e dificulta a navegação com tecnologias de apoio.

  Recomendação

  É necessário rever todas as páginas para garantir que os elementos interativos podem ser accionados através de outros tipos de interação como o teclado.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #53 Há elementos interativos com área clicável que não cumprem a dimensão mínima exigida

  etiqueta: chk conteúdoetiqueta: NOKetiqueta: R 5.2

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

  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.

  O website apresenta elementos interativos com dimensões menores que o recomendado para área clicável. Por exemplo, a página Freguesias as imagens-link “Pesquisa” e “Login” com largura com altura de 38.38px. E o botão de "Contactos", com 37px de altura. Não cumprem as dimensões mínimas necessárias. (Figura 1)

  

  Figura 1 - Página Freguesias e elementos interativos com dimensão inferior ao recomendado

  O mesmo problema acontece na modal de login com o botão “Fechar” com largura e altura de 15px. Não cumprem as dimensões mínimas necessárias para áreas clicáveis. Tornando difícil a seleção especialmente para dispositivos sensíveis ao toque. (Figura 2)

  

  Figura 2 - Botão "Fechar" da modal de login, com dimensão inferior ao recomendado

  A dimensão de elementos interativos das redes sociais nas páginas interiores é menor que 44px. Por exemplo, a página Notícias os ícones “Facebook” com largura e altura de 22.5px. Não cumprem as dimensões mínimas necessárias para áreas clicáveis.

  

  Figura 3 - Elementos interativos das redes sociais com dimensão inferior ao recomendado

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

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #54 Há botões principais que não têm destaque suficiente

  etiqueta: chk conteúdoetiqueta: NOKetiqueta: R 5.3

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

  Notas gerais

  • Os botões de ação principal devem estar destacados numa página ou num bloco de informação para tornar mais percetível o local onde os utilizadores devem clicar para realizar uma determinada tarefa. Pela mesma razão, os botões secundários devem estar menos destacados e com um estilo diferente. Ao garantirmos uma hierarquia dos botões, reduzimos a probabilidade de ações secundárias serem confundidas com ações principais.

  Na página Turismo, consideram-se como botões principais “Ver agenda” e “Conhecer” . Observa‑se que vários botões apresentam o mesmo estilo visual e ão possuem destaque face aos restantes botões da página, nomeadamente os botões “Conhecer”, repetidos em múltiplos cartões da área de Turismo. (Figura 1)

  

  Figura 1 - Botões primários e secundários não são diferenciados

  Embora estes elementos permitam explorar diferentes categorias turísticas, o seu estilo coincide com o dos botões utilizados como ações principais noutras secções do site. Esta falta de hierarquia visual impede o utilizador de identificar de forma imediata se existe uma ação prioritária na página, violam o presente requisito, que determina a existência de apenas um botão de ação principal destacado por página.

  O mesmo acontece na página Heraldica, o botão de ação principal “Conhecer mais” possui o mesmo estilo dos botões de ação secundária. Além disso, não há contraste suficiente para sinalizar a ação prioritária. (Figura 2)

  

  Figura 2 - Página "Heráldica" botões primários e secundários não são diferenciados

  Existem botões principais e secundários com o mesmo estilo como por exemplo na página Ambiente (Figura 3)

  

  Figura 3 - Página "Ambiente" botões primários e secundários não são diferenciados

  Recomendação

  • Para melhorar a acessibilidade e a clareza de navegação, recomenda‑se que todos os botões “Conhecer” sejam tratados como botões secundários, com um estilo uniforme e não destacado, dado que representam opções equivalentes. Caso exista uma ação prioritária global na página de Turismo, essa ação deve ser apresentada isoladamente no topo e com um estilo visual contrastante.

  • Os botões principais devem contrastar face ao restante conteúdo da página e blocos de informação. Pode-se também distinguir os botões através da forma (ex: preenchimento, delineamento, cantos arredondados).

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #55 Elementos interativos não aparentam ser clicáveis

  etiqueta: chk conteúdoetiqueta: NOKetiqueta: R 5.4

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

  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.

  Na página Hillstar Eventos, existe um conjunto de elementos gráficos interativos que não apresentam qualquer indicação visual de clicabilidade. (Figura 1)

  

  Figura 1 - Elementos interativos (círculos) não aparentam ser clicáveis

  Na secção apresentada, os círculos destacados que funcionam como controlos de navegação de um carrossel com cinco itens não evidenciam qualquer característica visual que permita ao utilizador identificar que são elementos interativos. A ausência de contrastes visuais, estados destacados, alteração de forma, relevo ou qualquer pista perceptível de ação impede a sua identificação como botões funcionais.

  Esta ausência de pistas visuais viola o presente requisito, que exige que todos os elementos gráficos clicáveis aparentem ser interativos através de forma, cor ou aparente volume, comprometendo a perceção, usabilidade e acessibilidade da interface.

  Problemas de contraste em elementos interativos

  A análise do website revela que existem elementos interativos que não possuem contraste suficiente. Como por exemplo, na página inicial as setas interativas da secção “Avisos” com taxa de contraste (1,7:1) valor inferior ao mínimo recomendado. (Figura 1)

  

  Figura 1 - Página inicial do website em análise de contraste com ferramenta Color Contrast Analyser

  Esta prática dificulta utilizadores com baixa visão reconhecer elementos clicáveis. Acontece o mesmo problema de contraste com a combinação das cores #FFFFFF(cor de primeiro plano) e #FCB829(cor de plano de fundo) nos elementos interativos ativos das paginações em Notícias (Figura 2)

  

  Figura 2 - Elementos interativos das páginações não passam na avaliação de contraste

  Nos ícones da página Documentação online | Transparência Municipal , assim como nas setas do carrossel, que possuem baixo contraste com a cor #FCB829 e tornam-se pouco visíveis sobre o fundo das imagens do banner. (Figura 3)



  

  Figura 3 - Elementos interativos do carrossel pouco visíveis e com baixo contraste em relação a imagem de fundo

  Recomendação de melhoria
  É necessário rever o website para que em outros locais não existam elementos interativos com a mesma combinação de cores que não passam na avaliação de contraste.

etiqueta: N/A

Lista de evidências recolhidas:

• evidência: issue #57 Não existem formulários com mais de 2 ecrãs no website

  etiqueta: N/Aetiqueta: R 1.2etiqueta: chk 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

  Não existem formulários com mais de 2 ecrãs no website, portanto o critério é considerado "Não aplicável (N/A)".

etiqueta: N/A

Lista de evidências recolhidas:

• evidência: issue #58 Não existem formulários com mais de uma página no website

  etiqueta: R 1.3etiqueta: N/Aetiqueta: chk 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

  Não existem formulários com mais de uma página no website, portanto o critério é considerado "Não aplicável (N/A)".

etiqueta: N/A

Lista de evidências recolhidas:

• evidência: issue #60 Os formulários são curtos e apresentam todos os campos de uma vez

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

  É usada revelação progressiva em vez de campos inativos.
  – ver requisito 2.2 na lista Transação

  O critério é "Não aplicável (N/A)".
  Os formulários disponíveis no website apesar de apresentarem-se desencadeados em um acordeão. Não possuem campos dependentes de outros, pois são três formulários diferentes. (Figura 1):

  

  Figura 1 - Formulários curtos sem dependência de revelação progressiva

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #62 Campos obrigatórios não são claramente indicados como tal

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

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

  Notas Gerais

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

  No formulário da página Documentação online | Transparência Municipal não existe informação sobre o que é o * dos campos. (Figura 1)

  

  E na modal de login os campos “Nome” e “Palavra-passe” não são identificadas como campos de preenchimento obrigatório. (Figura 2)

  

  Recomendamos a revisão dos formulários, devendo:

  • Identificar os campos obrigatórios colocando o texto “Obrigatório” em todos os campos obrigatórios ou um * ou símbolo e o respetivo significado no início do formulário.
  • Adicionar uma legenda no início do formulário que indique claramente o significado de *.

etiqueta: N/A

Lista de evidências recolhidas:

• evidência: issue #63 Não existem ações longas no website

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

  Em ações longas, o sistema deve indicar o que está a acontecer.
  – ver requisito 3.1 na lista Transação

  Não existem ações longas no website, o envio do formulário é imediato. O critério é considerado "Não aplicável (N/A)".

etiqueta: N/A

Lista de evidências recolhidas:

• evidência: issue #65 Não existem formulários com ações consideradas destrutivas (Não Aplicável)

  etiqueta: N/Aetiqueta: R 4.2etiqueta: chk 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

  Não foi identificado ações consideradas destrutivas nos formulários do website. É necessário corrigir a checklist, onde indicam “Sim” mas consideramos "Não aplicável (N/A)"

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

Lista de evidências recolhidas:

• evidência: issue #66 Não são devolvidas mensagens de erro simultaneamente em cada campo do formulário

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

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

  Notas Gerais

  • Os campos dos formulários devem devolver mensagens de erros relativas ao problema encontrado em cada campo, que devem ser identificadas visualmente e pelo leitor de ecrã.

  Apenas aparece uma mensagem de erro num dos campos por vez, mesmo quando outros campos também apresentam erros pois são campos vazios sem preenchimento. (Figura 1 e 2)

  

  Figura 1 - Formulário "Contacte-nos" informa um erro por vez

  

  Figura 2- Formulário "Sugestões" apenas informa o erro do e-mail incorreto, não avisa sobre os outros campos vazios simultaneamente

  É uma boa prática informar os utilizadores sobre os erros antes da submissão do formulário. Desta forma, evitam ter de regressar a cada campo para corrigir problemas, algo particularmente importante para pessoas que utilizam leitores de ecrã.

  Recomendações

  • Recomendamos a revisão dos formulários, para garantir que devolvem mensagens de erro junto aos campos com dados preenchidos incorretamente ou não preenchidos de todo.
  • Indicar quais são os campos de preenchimento obrigatório e que não podem ser submetidos vazios.
  • Exemplo de boa prática para formulários com erros associados aos respetivos campos, Site do Selo

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #75 Outras violações - Formulários indisponíveis

  etiqueta: NOKetiqueta: outras violações

  Descrição do problema:
  Alguns formulários encontram-se indisponíveis ao clicar em links dos formulários o utilizador é direcionado a página de pesquisa onde não é encontrado o formulário.

  Os formulários disponíveis na página Programa de Férias + Solidárias apresenta este comportamento com o acesso aos links disponíveis. (Figura 1)

  

  Figura 1 - "Formulário Inscrição Férias Ocupadas" direciona para página de "Pesquisa"

  No entanto ao interagir com os links, como por exemplo ao selecionar o formulário Inscrição Férias Ocupadas o resultado da pesquisa não é para um formulário e sim para um card “Programa de Férias + Solidárias” que faz o utilizador retornar a página onde o formulário foi acionado, sem obter informações sobre o preenchimento do formulário. (Figura 2)

  

  Figura 2- Página de "Pesquisa" com formulário não encontrado, apenas com card para a página anterior

  Páginas que apresentam formulários com o mesmo problema:

  • https://www.cm-oliveiradohospital.pt/servicos/acao-social/recrutamento-de-juizes-sociais/
  • https://www.cm-oliveiradohospital.pt/wpfd_file/pdf-2-a-revisao-do-plano-de-pormenor-da-zona-industrial-de-oliveira-do-hospital-planta-de-implantacao/#content
  • https://www.cm-oliveiradohospital.pt/orcamento-participativo-jovem-2022-apresentacao-de-propostas-ate-final-de-setembro/

  Recomendação de melhoria
  É recomendada a correção dos links associados aos formulários, garantindo que cada ligação direcione o utilizador para o conteúdo correto em vez de o redirecionar para a página de pesquisa sem resultados relevantes. Esta melhoria assegura o acesso eficaz aos formulários, como os do "Programa de Férias + Solidárias" e outras páginas identificadas evitando ciclos de navegação que impedem o preenchimento e a consulta da informação pretendida.

• evidência: issue #74 Outras violações - Formulários em PDF e indisponíveis para preenchimento digital

  etiqueta: NOKetiqueta: outras violações

  Notas Gerais

  • Os formulários disponibilizados em formato PDF apresentam limitações significativas de acessibilidade. Embora alguns campos permitam navegação através das teclas direcionais, muitos não fornecem informações completas aos utilizadores de tecnologias de apoio.

  No caso do formulário OPJ (Orçamento Participado Jovem) , campos essenciais como “Tipo de Participação” e “Identificação” não são anunciados pelos leitores de ecrã, tornando o conteúdo inacessível para pessoas com deficiência visual. (Figura 1)

  

  Figura 1 - Navegação pelo formulário com perda de informações sobre os campos de preenchimento

  Recomendação de melhoria:

  • Idealmente, os formulários devem ser disponibilizados em formatos acessíveis estruturados como página HTML assegurando navegação sequencial correta, descrição completa dos campos e compatibilidade com tecnologias de apoio.
  • Recomendamos a criação dos formulários em conformidade com as boas práticas de acessibilidade digital, garantindo que todos os campos sejam devidamente identificados, etiquetados e anunciados por leitores de ecrã. Esta melhoria permitirá o preenchimento autónomo e inclusivo.

• evidência: issue #73 Outras violações - Botões "Diminuir" e "Aumentar" fontes causam problemas de acessibilidade com blocos de textos

  etiqueta: NOKetiqueta: outras violações

  Problema identificado

  Na página Percurso Pedestre de Avô os botões de acessibilidade “Diminuir” e “Aumentar” estão a gerar alterações extremas no tamanho do texto, resultando na apresentação de conteúdos ilegíveis (Figura 1).

  

  Figura 1 - Utilização do botão "Aumentar" causa problemas de legibilidade do conteúdo, com espaçamento incorreto

  Este comportamento compromete a leitura, a navegação e a compreensão da informação, constituindo uma barreira de acessibilidade para todos os utilizadores, especialmente para pessoas com baixa visão ou dificuldades cognitivas.

  Recomendação de melhoria

  Ajustar o funcionamento dos controlos de zoom de texto, definindo limites mínimos e máximos adequados, de forma a garantir que o aumento ou diminuição do tamanho da letra mantém o conteúdo legível e corretamente formatado. Recomenda‑se também validar o comportamento em diferentes dispositivos e tamanhos de ecrã, assegurando uma experiência acessível e consistente.

• evidência: issue #72 Outras violações - Ficheiro ZIP não encontrado

  etiqueta: NOKetiqueta: outras violações

  #####Problema identificado:


  Foi identificado que o ficheiro ZIP correspondente ao Mapa de Ruído composto pelo Relatório, Resumo Não Técnico e peça desenhada à escala 1/25000, disponibilizado na página Instrumentos de Gestão Territorial (PDM e PP) e Regeneração Urbana não pode ser descarregado. (Figura 1)

  

  Figura 1 - Ficheiro ZIP não encontrado, leva a página de erro 404

  A hiperligação aponta para um recurso inexistente, originando uma página de erro 404. Esta situação impede o acesso à informação obrigatória e constitui uma barreira significativa, sobretudo para utilizadores que dependem de leitores de ecrã ou navegação por teclado, que não recebem qualquer aviso de indisponibilidade. Além disso, o texto da página não deixa claro que se trata de links para download, contrariando o Requisito 3.3 da Checklist de Conteúdo, que exige que hiperligações sejam claramente identificadas e compreensíveis.

  Recomendação de melhoria

  Recomenda‑se atualizar todas as hiperligações para garantir que apontam para ficheiros efetivamente disponíveis para download. O texto associado aos links deve ser reformulado para informar explicitamente que se trata de ficheiros descarregáveis (ex.: “Descarregar Mapa de Ruído (ZIP)”). Adicionalmente, deve ser assegurado que os links cumprem as boas práticas de acessibilidade: serem descritivos, distinguíveis e fornecerem informação clara sobre o tipo e objetivo do ficheiro.

• evidência: issue #71 Outras violações - Caracteres especiais não são lidos corretamente pelos leitores de ecrã

  etiqueta: NOKetiqueta: outras violações

  Problema identificado:

  Na página Instrumentos de Gestão Territorial (PDM e PP) e Regeneração Urbana , o ordinal “2.ª” é lido incorretamente pelos leitores de ecrã porque os caracteres são interpretados de forma isolada. (Figura 1)

  

  Figura 1 - Conteúdo da página contém caracteres especiais que dificultam a interpretação textual com leitores de ecrã

  Para evitar esta ambiguidade um problema reconhecido nas orientações do W3C, que recomendam evitar símbolos ou formatações que possam ser lidas de modo inadequado por tecnologias de apoio

  Recomendações de melhoria
  Recomenda‑se substituir abreviações como “2.ª” por formas claras e inequívocas, preferencialmente ordinais por extenso, como “segunda”, ou alternativas híbridas como “2ª (segunda)”. Esta simplificação alinha‑se também com as boas práticas de escrita acessível que privilegiam linguagem clara e compreensível para todos os utilizadores.

  Se precisar de manter o formato ordinal com número, pode usar o elemento com o atributo title, que fornece ao leitor de ecrã a forma completa:

  • <p>A <abbr title="segunda">2ª</abbr> fase está em curso.</p>

• evidência: issue #70 Outras Violações - Animação de letras provoca leitura fragmentada pelo NVDA

  etiqueta: NOKetiqueta: outras violações

  Problema identificado:
  Na página Freguesias há uma animação com palavras em destaque, onde o título apresentado utiliza uma animação que divide cada palavra em múltiplos elementos , aplicando transformações e efeitos visuais individuais para cada letra. (Figura 1)

  

  Figura 1- Palavras com animação visual segregam informação da palavra

  Esta técnica, apesar de decorativa, altera completamente a estrutura textual do conteúdo, fazendo com que leitores de ecrã como o NVDA interpretem e anunciem o texto letra por letra, ou mesmo incluam espaços e caracteres vazios que resultam da manipulação visual. O mesmo acontece nas páginas interiores do Turismo.

  Como consequência, o utilizador recebe uma leitura fragmentada, incompreensível e desconexa, comprometendo a perceção e compreensão da informação. (Figura 2)

  

  Figura 2 - Leitura incorreta de palavras, por caracteres com leitor de ecrã NVDA

  Além disso, esta prática viola os princípios de acessibilidade que exigem que o conteúdo textual seja disponibilizado de forma linear, sem interferências que prejudiquem tecnologias de apoio.

  Recomendação de Melhoria

  Recomenda-se substituir a técnica atual de animação por uma solução que mantenha o texto intacto no DOM, garantindo que leitores de ecrã acedam ao conteúdo como uma única unidade coerente. Caso a animação seja indispensável do ponto de vista visual, deve ser aplicada ao elemento completo (ex.: ao <h3> ou ao <span> que contém o texto integral), evitando a criação de <span> individuais por letra. Alternativamente, pode ser usada uma versão acessível, como manter o texto real oculto apenas visualmente e animar uma versão decorativa marcada como aria-hidden="true". Assim assegura-se que a experiência permanece esteticamente apelativa, sem comprometer a acessibilidade e a compreensão do conteúdo por utilizadores de tecnologias de apoio.

• evidência: issue #69 Outras violações - Ficheiros PDFs não podem ser baixados

  etiqueta: NOKetiqueta: outras violações

  Descrição do problema

  Os ficheiros PDF disponibilizados no website não podem ser baixados pelos utilizadores, impedindo o acesso e a consulta dos conteúdos pretendidos.

  Na página “Estádio Municipal ” ao clicar em “Download do Regulamento das Instalações Desportivas” (Figura 1)

  

  Figura 1 - Botão com link para "Download do Regulamento das Instalações Desportivas"

  O utilizador é redirecionado para a página de “Pesquisa” (Figura 2)

  

  Figura 2 - Redirecionamento incorreto dos ficheiros para página de "Pesquisa"
  O mesmo acontece com outros ficheiros encontrados no website, por exemplo da página Documentação online | Transparência Municipal :

  Código de Conduta
  Despacho
  Norma de Controlo Interno
  Plano de Prevenção de Riscos
  Programa de Formação

  Recomendação de melhoria

  Recomendamos a correção destes links, garantindo que cada botão ou hiperligação conduz diretamente ao documento correspondente, permitindo o acesso e download adequados dos ficheiros.