Relatório Avaliação da Candidatura da SMOS(Sistema de Monitorização da Ocupação do Solo)

Introdução

O website https://smos.dgterritorio.gov.pt/ etiqueta: não passa nos requisitos mínimos do Selo de Usabilidade e Acessibilidade.

Estado das avaliações efetuadas
Tipo de avaliação Estado
Avaliação Automática etiqueta: NOK
Avaliação Manual etiqueta: NOK

Das avaliações manuais efetuadas obtiveram-se os resultados que se sintetizam na tabela seguinte.

Níveis de conformidade das avaliações manuais
Checklist Conformidade alcançada Resultado
10 aspetos 50.0% (13/26) etiqueta: Não passa
Conteúdo 41.2% (7/17) etiqueta: Não passa
Transação 41.7% (5/12) etiqueta: Não passa

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

Avaliação automática

etiqueta: NOK

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

Lista de evidências recolhidas:

Avaliação manual

etiqueta: NOK

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

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

Checklist 10 aspetos

etiqueta: NOK

Nível de conformidade:

  • Checklist 10 aspetos: 50.0% (13/26)
    • Requisitos avaliados: 27 (1 N/A excluído, 26 aplicáveis)
    • Requisitos OK: 13
    • Requisitos NOK: 13
    • Requisitos N/A: 1

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue#1 Há opções do menu que não estão estruturadas como lista

    • etiqueta: chk 10 webetiqueta: NOKetiqueta: R 1.1

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

      Descrição do problema:

      Há opções do menu que não estão estruturadas como lista (ul) e (li)

      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)

      Na página inicial o menu principal do header encontra-se estruturado com elementos

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue#2 Não é possível navegar com o teclado para as sub-opções do menu, sem percorrer primeiro todas as opções do 1º nível

    etiqueta: chk 10 webetiqueta: NOKetiqueta: R 1.2

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

    Notas gerais

    Para garantir uma navegação livre por todas as opções do menu, é importante estruturá-las como listas, utilizando elementos ul e li. As opções de primeiro nível devem conter uma lista com suas respetivas opções de segundo nível para que seja possível navegar por elas assim que a opção de primeiro nível for selecionada.

    Descrição do problema:

    No caso do menu principal da página inicial, este não está todo estruturado como lista. Por esse motivo, apesar do foco do teclado voltar para as opções do primeiro nível, as subopções do segundo nível mantêm-se abertas, o que leva o foco a voltar para as subopções após terminar de percorrer as opções de primeiro nível.

    Submenus que abrem sem ter sido escolhidos explicitamente, forçando o utilizador de leitor de ecrã a atravessar todas as opções. Falta de feedback de que o submenu se expandiu ou recolheu. Itens de segundo nível que não são anunciados como tal e não indicam que podem ser expandidos. (Figura 1)

    Image

    Figura 1 - Menu com leitor de ecrã NVDA, navegação por todas as opções e subopções

    Nas páginas interiores, a navegação obriga a percorrer todos os elementos do menu em cada página, o que torna a navegação lenta e cansativa para utilizadores que necessitam de tecnologias de apoio. (Figura 2)

    Image

    Figura 2 - Menu das páginas interiores com leitor de ecrã NVDA, navegação por todas as opções e subopções

    Recomendação de melhoria

    Para que a navegação correta via teclado seja possível, o menu deve ser estruturado com os elementos corretos (ul e li). Não ativar automaticamente submenus em páginas interiores, o menu deve expandir apenas por escolha do utilizador, para permitir saltar mais rapidamente para o conteúdo.

    As subopções devem estar inseridas nas opções de 1º nível do menu. A estrutura deve ser:

Requisito 1.3 - As imagens-link, caso existam no menu, devem ter o correspondente equivalente alternativo em texto

etiqueta: N/A

Lista de evidências recolhidas:

  • issue#16 Não Aplicável - Menu não possui imagens-link

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

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

    O requisito 1.3, imagens-link não se aplica ao website, uma vez que o menu de navegação não utiliza imagens como elementos de ligação. Todos os itens do menu são apresentados através de texto, sem recorrer a ícones ou imagens clicáveis, pelo que este critério não é aplica-se para a avaliação.

    Recomendamos atualizar requisito na checklist dos 10 aspetos como "Não Aplicável -NA"

Requisito 2.2 - Existe uma marcação hierarquizada de títulos e subtítulos na página (<h1>...<h6>)

etiqueta: NOK

Lista de evidências recolhidas:

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

    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

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

    Descrição do problema:

    Verificou-se que existem páginas em que a hierarquia de títulos não está a ser respeitada. Nas páginas dos visualizadores há problemas na hierarquia de cabeçalhos. Por exemplo na página COScid com dois h1, o que quebra o princípio de “um título principal por página” e um salto do título h1 para h3. (Figura 1)

    Image

    Figura 1 - Visualização da página COScid com estrutura incorreta de cabeçalhos

    E na página viSMOS com saltos de nível, como h1 diretamente para h5, sem passagem por h2, h3 ou h4. (Figura 2)

    Image

    Figura 2- Visualização da página viSMOS com estrutura incorreta de cabeçalhos

    Nestes casos, a estrutura lógica do conteúdo fica confusa para leitores de ecrã e para quem usa navegação por headings (por exemplo, tecla H / lista de títulos).

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

Requisito 4.1 - Ao clicar com o rato na etiqueta, o cursor surge no respetivo campo de edição

etiqueta: NOK

Lista de evidências recolhidas:

  • issue#4 Problemas de associação label aos respetivos campos

    etiqueta: chk 10 webetiqueta: NOKetiqueta: R 4.1

    Ao clicar com o rato na etiqueta, o cursor surge no respetivo campo de edição.
    – ver requisito 4.1 na lista 10 aspetos

    Existem etiquetas que não estão associadas ao seu respetivo campo

    Os campos de formulários devem ter as suas legendas estruturadas com o elemento label, fieldset e legend, para que ao clicar na legenda o cursor seja movido para o campo.

    A página do visualizador viSMOS possui controlos de formulário sem um nome acessível, ou seja, não possuem label atribuída. Por exemplo, as checkbox não possuem labels devidamente associados ao campo. Sendo assim, o leitor de ecrã apenas anuncia “caixa de seleção” não relacionando com a checkbok com o texto da opção. (Figura 1)

    Image

    Figura 1 – Checkboxs do visualizador viSMOS, com campos sem labels atribuídas

    Recomendações

    Recomendamos a revisão das páginas do site, para garantir que todos os formulários estão bem construídos. A legenda dos campos das checkbox devem estar estruturadas no elemento

    O texto placeholder está a substituir a label

    Não deve ser usado o texto placeholder em substituição de uma label, porque ao escrever no campo esse texto irá desaparecer e torna a tarefa difícil para pessoas com problemas de memória ou na revisão das respostas do formulário. Para além disso, alguns leitores de ecrã podem não estar preparados para ler esse texto.

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

    Na modal "Criar utilizador" da página do visualizador COSvgi, existem campos de formulários como por exemplo “Username” e “Palavra-passe” sem label programaticamente associado, são apenas placeholder consequentemente não são anunciados leitor de ecrã NVDA sendo assim não é possível identificar como campos obrigatórios. (Figura 2)

    Image

    Figura 2 – Etiquetas substituídas por placeholders, nos campos obrigatórios do formulário Criar utilizador

    Recomendações

    Recomendamos a revisão dos formulários para garantir que:

    • São atribuídas legendas aos campos utilizando o elemento label;

    • O texto placeholder, quando utilizado, auxilia no preenchimento do campo em vez de substituir a legenda;

    • Caso seja usada a legenda dentro do campo, esta deve estar identificada como

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

    Existem label no código mas visualmente escondido com CSS

    O campo de pesquisa apresenta um label existente no código, mas este encontra-se aplicado com a classe visually-hidden, o que o torna invisível para o utilizador apesar de continuar acessível para tecnologias de apoio. Consequentemente, apenas o placeholder “Pesquisar” é visível no campo, o que não substitui um label e prejudica a compreensão do propósito do campo, sobretudo para utilizadores com dificuldades cognitivas ou quando o texto desaparece ao começar a digitar. (Figura 3)

    Image

    Figura 3 – Etiqueta escondida do campo de pesquisa

    Esta prática compromete a perceção visual da interface, contrariando os princípios semânticos das WCAG, que recomendam o uso de elementos HTML apropriados para garantir clareza e interpretação correta pelos utilizadores e tecnologias de apoio. Menus, listas e campos devem manter semântica reconhecível mesmo sem CSS, garantindo estruturas bem definidas.

    Recomendação

    Recomendamos a revisão da páginas do site para garantir que todos os formulários estão bem construídos. No campo de pesquisa, tornar label "Pesquisar" visível na interface, mantendo simultaneamente a semântica e acessibilidade. O label deve identificar claramente a função do campo e não depender apenas do placeholder, caso seja necessário manter texto do placeholder apenas como apoio opcional.

Requisito 4.2 - É possível identificar os campos de preenchimento obrigatório quando se usa apenas um leitor de ecrã

etiqueta: NOK

Lista de evidências recolhidas:

  • issue#5 Há campos que não são identificados como obrigatório pelo leitor de ecrã

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

    Notas gerais

    • Os campos dos formulários devem estar devidamente construídos e identificados como obrigatórios através do HTML.
    • Os campos obrigatórios de um formulário devem ser visíveis para as tecnologias de apoio. Caso contrário, podem surgir dificuldades no seu preenchimento. Por exemplo, um utilizador que utilize um leitor de ecrã poderá não conseguir submeter o formulário porque não será possível preencher os campos de preenchimento obrigatório.
    Descrição do problema:

    Na página COSvgi a modal "Entrar - COSvgi" possui campos obrigatórios que não são identificados como tal. Apenas ao submeter formulário com os campos "Utilizador/E-mail" e "Palavra-passe" vazios, são atribuídas mensagens "Preenchimento obrigatório" mesmo assim são apresentadas apenas visualmente com o texto em vermelho e não são anunciados como campos obrigatórios pelos leitores de ecrã. (Figura 1)

    Image

    Figura 1- Modal com campos obrigatórios não são anunciados pelos leitores de ecrã.

    Observamos que a correção foi feita para adicionar uma legenda no início do formulário "Criar utilizador" que indica claramente o significado de * com o texto "* Campo de preenchimento obrigatório". No entanto, há campos que não possuem um label atribuído, apenas o placeholder informa que existem campos obrigatórios. Por exemplo “Username*” e “Palavra-passe*”, sendo assim, o leitor de ecrã não reconhece os campos como obrigatórios. (Figura 2)

    Image

    Figura 2- Campos obrigatórias não identificados.

    Os campos dos formulários devem estar devidamente construídos e identificados como obrigatórios através do HTML. É possível fazer isso de duas formas:

    Se utilizar o atributo de HTML5 required, ou seja, <input .... required>

    Se utilizar o atributo aria-required, ou seja, <input ... aria-required="true">,

    Recomendações

    Recomendamos a revisão dos formulários para garantir que estão bem construídos, recorrendo ao atributo required ou aria-required.

Requisito 4.3 - É possível localizar e ler as mensagens de erro usando apenas um leitor de ecrã

etiqueta: NOK

Lista de evidências recolhidas:

  • issue#6 Não é possível localizar e ler as mensagens de erro usando apenas um leitor de ecrã

    etiqueta: chk 10 webetiqueta: NOKetiqueta: R 4.3

    É possível localizar e ler as mensagens de erro usando apenas um leitor de ecrã.
    – ver requisito 4.3 na lista 10 aspetos

    Notas Gerais

    • Os campos dos formulários devem devolver mensagens de erros relativas ao problema identificado em cada campo, que devem ser identificadas visualmente e pelo leitor de ecrã.
    As mensagens de erro não estão visíveis, nem são lidas pelo leitor de ecrã

    Na página COSvgi, foram identificados vários problemas relacionados com mensagens de erro em cada campo. Na modal de login quando o utilizador introduz credenciais sem validar novo registo por e-mail, aparece apenas mensagem genérica (“Nome de utilizador ou palavra‑passe inválido”) sem orientação clara da correção do erro e associação aos campos. (Figura 1)

    Image

    Figura 1 - Modal de login, associação de mensagens de erros aos campos genérica e incorreta

    Este é um exemplo de primeiro acesso após criar registo, no entanto não é evidente que o utilizador precisa validar o registo por email. A interface apresenta apenas a mensagem genérica “Nome de utilizador ou palavra‑passe inválido”, mesmo quando as credenciais estão corretas, criando confusão e impedindo o avanço.

    Além disso, quando o utilizador introduz dados incorretos, não é possível prosseguir na navegação, uma vez que o ecrã de erro não oferece orientações claras para correção do erro, para sair, fechar ou recomeçar o processo.

    Recomendações

    Recomenda‑se melhorar a clareza e a associação das mensagens de erro aos respetivos campos, garantindo uma orientação adequada ao utilizador. Exemplos:

    • Nome de utilizador inválido

    • Palavra‑passe inválida

    • Se é um novo utilizador, confirme o registo no email antes do primeiro acesso

    Estas melhorias reforçam a acessibilidade, reduzem frustração e asseguram uma experiência mais clara e compreensível para todos os utilizadores.

    As mensagens de erro não são lidas pelo leitor de ecrã

    As mensagens de erro que surgem durante o preenchimento de um formulário devem estar associadas aos respectivos campos.

    Na modal de login os erros devolvidos não estão associados aos respectivos campos, apesar das mensagens estarem visualmente posicionadas próximas dos campos a que dizem respeito não são anunciadas pelo leitor de ecrã. Por exemplo na etapa “Registo de utilizador” não foi anunciado pelo leitor de ecrã a mensagem de erro visível em vermelho “Email inválido. E.g. exemplo@email.pt” (Figura 2)

    Image

    Figura 2 - Modal registo de utilizador com mensagens de erro não anunciadas pelo leitor de ecrã NVDA

    A associação entre a mensagem de erro e o respectivo campo é essencial para as pessoas que utilizam tecnologias de apoio para navegar no site. Pois sem esta associação, o leitor de ecrã, que não consegue reconhecer a ligação entre a mensagem de erro e o campo a que diz respeito.

    Recomendações

    Recomendamos a revisão dos formulários para garantir que as mensagens de erro estão associadas aos respectivos campos.

    Para mais informações sobre boas práticas de apresentação de mensagens de erro nos formulários, podem consultar a página da WAI sobre Notificações para utilizadores.

    Deve-se aplicar o atributo required aria-describedby="" para que as mensagens de erro fiquem associadas aos respectivos campos e que essa associação seja detectada pelos leitores de ecrã.

    Outros atributos que podem ser utilizados como complemento são:

    • O atributo role=”alert”, que força os leitores de ecrã a reconhecer o elemento assim que ele se torna visível.

    • O atributo role=”aria-live=”assertive”, que força os leitores de ecrã a ler essa mensagem em primeiro lugar.

    Exemplo de mensagem de erro acessível:

Requisito 5.1 - A imagem ou gráfico tem um equivalente alternativo em texto curto e correto

etiqueta: NOK

Lista de evidências recolhidas:

  • issue#7 Imagem ou gráfico sem textos alternativos ou 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 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.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.
    Imagem informativa com texto alternativo incorreto

    Na página Ajuda existe uma imagem com explicação sobre o visualizador COScid, que apesar de possuir uma descrição longa correta. Possui um texto alternativo alt="janelainicial" incorreto. Com esse texto os leitores de ecrã não passam a informação síntese da imagem. (Figura 1)

    Image

    Figura 1- Página ajuda do COScid e imagem com texto alternativo incorreto

    Recomendação de melhoria:
    Rever imagens do website incluir ou corrigir textos alternativos.

    Mapas interativos em canvas, não possuem um nome acessível

    Identificamos que o mapa interativo dos visualizadores, está implementado por um Canvas que não têm um nome acessível, para informar utilizadores de tecnologias assistiva que existe um mapa interativo com foco no mapa de Portugal. Por exemplo na página do visualizador COSvgi (Figura 2)

    Image

    Figura 2- Página ajuda do COSvgi com mapas interativos sem texto alternativo

    Destacamos que é essencial a visualização do mapa pela maioria das ferramentas interativas disponíveis nos visualizadores estar associadas e relacionadas a este mapa. Tendo em vista que há um impacto dessas interações na visualização do gráfico, é necessário uma descrição alternativa coerente as respetivas interações. E um texto alternativo síntese que indique que existe um mapa disponível para interação, neste caso com o texto alternativo associado ao canvas.

    Na página do visualizador COScid em uma análise na secção “Dinâmicas” do Concelho de Abrantes, identificamos gráficos em SVG que são alterados de acordo com as informações disponíveis. Como por exemplo com a navegação pelo rato e visualmente, tornam-se percetíveis e compreensíveis através das interações, associações com o mapa e informações do menu lateral. (Figura 3)

    Image

    Figura 3- Gráficos em SVG sem texto alternativo

    No entanto, não existe um texto alternativo síntese para comunicar a existência deste gráfico ou até mesmo sobre o propósito das cores e relação dos dados, sendo assim há perda de informação para utilizadores cegos ou com baixa visão.

    Recomendação de melhoria:

    Sugestão de texto alternativo para a interação com o mapa:

    “Mapa de Portugal, com foco na região do Algarve marcação territorial e contornos em linha vermelha que circunscreve o mapa.”

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue#8 Gráficos complexos não possuem uma de descrição alternativa

    etiqueta: chk 10 webetiqueta: R 5.2etiqueta: NOK

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

    Verificou-se que gráficos de dados presentes nas páginas dos visualizadores não disponibilizam qualquer descrição longa ou alternativa como tabelas que acompanhe ou complemente a imagem. Isto ocorre em representações visuais onde a informação quantitativa, com opções de diferentes categorias ou comparativa é essencial para a compreensão do conteúdo, no caso dos visualizadores apenas está acessível visualmente.

    O visualizador COScid possui gráficos complexos que necessitam de interação e relação com mapa interativo. Os gráficos apresentados complementares, não possuem uma descrição síntese ou alternativa, sendo assim o leitor de ecrã anuncia informações quebradas da informação (Figura 1)

    Image

    Figura 1- Gráfico complexo na secção estatísticas sem descrição longa

    Recomendações
    A imagem complexa deve ser acompanhada não só de uma descrição curta, colocada como texto alternativo da imagem, mas também de uma descrição detalhada sobre o seu conteúdo, que represente de forma textual a informação mais relevante. Recomendamos a inclusão de uma tabela de dados como alternativa para apresentação de dados e que acompanhe a imagem.

    Existem outros gráficos disponíveis em SVG na “Barra de ferramentas COS série 2”, como por exemplo da secção “Dinâmicas”. Apesar de ser possível navegação pelo gráfico em SVG, está com informações desordenadas em relação ao sem conteúdo o que torna a solução ainda mais confusa para compreensão de informações através do leitor de ecrã. (Figura 2)

    Image

    Figura 2- Gráfico complexo na secção Dinâmicas sem descrição longa

    Não há uma descrição longa para explicar as relações das cores com os dados, por exemplo a marcação do território em vermelho e o equivalente alternativo para o quantitativo em hectares da agricultura, pastagens, florestas e matos.

    Recomendações
    Recomenda‑se que cada gráfico seja acompanhado de uma descrição longa, imediatamente presente na página, sintetizando as principais informações, categorias e conclusões representadas visualmente. Além disso, deve ser incluída uma tabela de dados equivalente, em HTML acessível, disponibilizando integralmente a informação original. Assegurando que leitores de ecrã reconhecem e anunciam o gráfico de forma apropriada.

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue#10 Imagens‑link não aparentam ser clicáveis

    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

    Imagens link com textos incorretos

    Nas páginas interiores dos visualizadores viSMOS , COScid e COSvgi o logotipo “SMOS”, localizado na barra superior, é uma imagem‑link que direciona para a página inicial do website e apresenta o texto alternativo alt="Logo SMOS". Embora o texto alternativo esteja correto em relação ao conteúdo visual da imagem, o elemento não deixa claro que se trata de um link que permite o retorno à página inicial do SMOS. (Figura 1)

    Image

    Figura 1- Imagens-link com title incorreto

    Recomendações
    O atributo title deve ser aplicado exclusivamente ao link correspondente e indicar claramente que, ao clicar, o utilizador será redirecionado para a página inicial. Assim, recomenda‑se corrigir para:
(<a href=”...” title="Ir para página inicial”>).

    Title duplicado em imagens-link

    Nos visualizadores foi identificado title duplicados atribuído simultaneamente ao link e à imagem do logotipo SMOS, como ocorre no visualizador viSMOS . (Figura 2)

    Image

    Figura 2- Title duplicado no logotipo SMOS

    Na mesma página do visualizador viSMOS foi identificada uma imagem‑link na secção “Temas” com texto alternativo incorreto. Apesar de a tag possuir o atributo title="Clique para abrir num separador", a imagem não apresenta texto alternativo. (Figura 3)

    Image

    Figura 3- Imagem-link no visualizador viSMOS, não apresenta texto alternativo sobre o seu conteúdo

    Contudo, visualmente contém informações relevantes sobre as cores associadas às áreas agrícolas. O mesmo problema ocorre nos menus do visualizador COSvgi, igualmente na secção “Temas”.

    Recomendações
    Em imagens, apenas o atributo alt deve ser usado; o title é opcional e deve ser aplicado exclusivamente ao link correspondente. Recomendamos a revisão das imagens-link para que incluam um texto alternativo, através do elemento (alt=”exemplo de texto alternativo”) e que descrevam o seu conteúdo correspondente.

  • issue#9 As imagens-link possuem textos 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 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.
    As imagens-link possuem um texto alternativo incorreto

    Nas páginas interiores do website, por exemplo em Tecnologia do espaço o logótipo apresenta-se como uma imagem-link que possui texto alternativo incorreto com alt="Ir para a página principal" o que não descreve corretamente o conteúdo da imagem, neste caso o logotipo. (Figura 1)

    Image

    Figura 1- Logotipo com textos alternativos incorretos

    Recomendamos incluir o atributo title para descrever corretamente a função e o destino da hiperligação por exemplo: <a href="..." title="Ir para a página inicial”> enquanto a imagem necessita de um texto alternativo correspondente ao que é visualmente percetível. Sendo assim, a correção deve ser aplicada com alt= SMOS (Sistema de Monitorização da Ocupação do Solo).

    Imagens-link das com textos não visíveis

    Textos alternativos associados às imagens –link das redes sociais não estão visíveis para todos utilizadores. Apesar dos ícones das redes sociais incluírem textos alternativos no respetivo código HTML, estes não são apresentados de forma visível ou percecionável devido à sua ocultação ou estilização inadequada. Como resultado, os utilizadores podem não conseguir identificar o propósito dos links, comprometendo a acessibilidade e a compreensão da navegação. (Figura 2)

    Image

    Figura 2- Imagens link no rodapé do website com textos não visíveis

    Além disso o logotipo DGT(Direção-Geral do Território)" apresenta-se como imagem-link e possui um texto alternativo que não descreve fielmente o logotipo apresentado com alt="logo da DGT", esse texto não informa sobre o redirecionamento para página externa da Direção-Geral do Território.

    Recomendações de melhorias

    Rever textos alternativos das imagens-link, para que informem corretamente sobre redirecionamento para páginas externas. O texto Redes sociais deve estar visível, pois ajuda os utilizadores que usam a visão a se situar que os ícones são referentes as respetivas redes sociais. Além disso, recomendamos alinhar ícones “Twitter” e “Youtube” à esquerda para manter a hierarquia dos elementos. Como por exemplo na (Figura 3)

    Image

    Figura 3- Exemplo de melhoria das imagens-link das redes sociais

    Imagens-link dos visualizadores com nome acessível incorretos

    Na página Visualizadores, os logotipos e as imagens de cada visualizador estão configurados como links que direcionam para páginas dos visualizadores. No entanto, o texto acessível dos links está incorreto, pois não informa aos utilizadores que ao clicar nas imagens acontecerá o comportamento de abrir novo separador.

    Image

    Figura 4- Imagens-link dos logotipos não possuem textos alternativos corretos e não aparentam ser clicáveis

    O texto atual não é descritivo nem claro para quem utiliza tecnologias de apoio. Além disso, a imagem não está semanticamente associada ao respetivo link, e há repetição de links no logotipo e na imagem do visualizador, o que pode causar confusão para os utilizadores. (Figura 5)

    Image

    Figura 5- Links redundantes em imagens-links

    Recomendações
    Recomendamos a correção do texto alternativo para que descreva fielmente o conteúdo da imagem de cada visualizador viSMOS, COScid e COSvgi, incluindo um conteúdo síntese descritivo do que de facto está visível nas respetivas imagens.

    Sugestões de melhorias dos textos alternativos

    • Exemplo viSMOS: alt=" Ecrã de computador portátil com o visualizador viSMOS aberto, mostrando um mapa colorido de Portugal e, à esquerda, um painel com opções de ocupação do solo.”

    • Logotipo viSMOS correção do texto alternativo para alt="Marca do Visualizador SMOS(Sistema de Monitorização da Ocupação do Solo)"

    • Logotipo COScid correção do texto alternativo para alt="Marca do visualizador COScid(Carta de Uso e Ocupação do Solo para o Cidadão)"

    • Logotipo COSvgi correção do texto alternativo para alt="Marca do visualizador COSvgi (Uso e Ocupação do Solo Informação Geográfica Voluntária)"

    Além disso, é necessário adicionar o atributo title associado ao link para tornar perceptível que na página existem imagens clicáveis.

    • Inserir tittle para indicar que existem links para direcionamento a página dos visualizadores title= “Abrir visualizador viSMOS”, title= “Abrir visualizador COScid” e title= “Abrir visualizador COSvgi”

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue#11 Texto normal não tem contraste suficiente

    etiqueta: R 6.1etiqueta: chk 10 webetiqueta: NOK

    No corpo de um documento, o rácio de contraste entre a cor do texto normal (menor que 18 pontos ou menor que 14 pontos negrito) e a cor do fundo é superior a 4,5:1.
    – ver requisito 6.1 na lista 10 aspetos

    Notas gerais

    • O contraste no texto normal (menor que 18 pontos ou menor que 14 pontos negrito) das páginas deve ser, no mínimo 4,5:1, para que pessoas com baixa visão consigam ler o texto.

    A avaliação com as ferramentas Colour Contrast Analyser e WAVE revelam problemas relacionados com insuficiência de contraste, afetando diretamente a legibilidade. Nas páginas viSMOS e COScid há problemas de contraste com a combinação de cores #FFFFFF (cor de primeiro plano) e #9EC222(cor de plano de fundo) (Figura 1)

    Image

    Figura 1- Páginas dos visualizadores com contraste inferior

    O mesmo acontece nas páginas de Ajuda dos visualizadores Ajuda - viSMOS e Ajuda - COScid com rácio de contraste inferior ao recomendado. (Figura 2)

    Image

    Figura 2- Páginas de Ajuda dos visualizadores com contraste inferior

    Assim como no visualizador COSvgi há textos com baixo contraste sobre o fundo. Com as combinações com o texto branco (#FFFFFF) sobre fundos em tons azul claro (#37B2DF), apresentam rácios inferiores ao mínimo exigido para texto normal (4,5:1). (Figura 3)

    Image

    Figura 3- Botões da modal do visualizador COSvgi com contraste inferior ao recomendado_

    Recomendações
    Recomendamos a revisão das cores das páginas as combinações de cores utilizadas em texto normal incluindo estados de foco e hover para garantir os valores mínimos de contraste, principalmente nos pares de cores dos visualizadores viSMOS, COScid e COSvgi.

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue#13 Problemas de Semântica e atributos incorretos

    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

    • O CSS é a linguagem utilizada para estilizar um documento HTML e descreve como os elementos devem ser apresentados. Ao removermos o layout, conseguimos verificar se é possível reconhecer o conteúdo e os elementos semânticos do documento HTML mesmo sem os estilos aplicados.
    Menu possui atributos button

    Menus e submenus devem ser corretamente interpretáveis por tecnologias de apoio, sendo necessário utilizar estruturas semânticas adequadas.

    No menu principal da página inicial identificamos, o uso de button para representar itens de navegação viola o presente requisito, segundo o qual, sem CSS, deve ser possível reconhecer a semântica dos elementos. (Figura 1)

    Image

    Figura 21 - Menu com estrutura semântica incorreta

    Com itens estruturados e implementados como button
 impedem que leitores de ecrã reconheçam a navegação como lista e que a hierarquia de opções e sub-opções seja anunciada, como descrito no Requisito 1.2.
 A semântica incorreta compromete a compreensão estrutural do conteúdo.

    Recomendação: Reestruturar e corrigir menus com elementos nativos nav, ul, li e links semânticos.

    ##### Botão hambúrguer implementado como div


    Elemento que abre/fecha o menu é um div, não anuncia ser botão nem o estado expandido/recolhido.
Existem outros botões que estão estruturados incorretamente como div, como por exemplo "Visualizadores" e "Saiba mais". (Figura 2)

    Image

    Figura 2 - Botões com semântica incorreta e atributo div

    Recomendação:
    É necessário a revisão de todo o website, para alterar botões que estão estruturados como div, quando na verdade são um atributo button. Recomendamos o usar aria-expanded, aria-label dinâmico para utilizadores terem feedback de comportamentos previsíveis.

    É necessário elementos HTML adequados para representar a função e o tipo de conteúdo, como listas, títulos e parágrafos garantindo relações e significado programaticamente determináveis.

    Carrossel com problemas de semântica

    Identificamos falhas de acessibilidade do carrossel, incluindo problemas de semântica, falta de feedback, ausência de alternativas textuais e impossibilidade de interpretação por leitores de ecrã.

    O carrossel da página inicial apresenta uma série de falhas estruturais e semânticas como setas e controlos não são anunciados por leitores de ecrã pois os Slider estão implementado com span sem semântica e interação por teclado. (Figura 3)

    Image

    Figura 3 - Carrossel com falhas semânticas

    Consequentemente mudanças de slide não são comunicadas e elementos interativos estruturados corretamente como botões reais e carecem de foco visível. Além disso, o conteúdo visual do slide não tem equivalente textual

    Tudo isto impede navegação eficaz por teclado, leitores de ecrã e tecnologias assistivas, comprometendo o cumprimento do presente requisito 8.3.

    Recomendação de melhoria

    Acrescentar textos alternativos e preferencialmente utilizar componentes nativos (ex.: button>, <input type="range") para garantir foco visível e navegação por teclado. Em alternativa, reestruturar todo o carrossel com semântica WAI‑ARIA adequada, aria-label, aria-controls, aria-expanded.

    Utilização de como slider interativo

    Os visualizadores viSMOS e COSvgi Possuem um slider interativo, que está implementado incorretamente com utilização do com role="slider" para simular um componente interativo. Apesar dos atributos ARIA, ele não fornece semântica, operação por teclado, feedback ou comportamento nativo, resultando num componente que não é verdadeiramente acessível. (Figura 4)

    Image

    Figura 4 - COSvgi com slider interativo inacessível

    é um elemento puramente decorativo e não interativo. Mesmo com role="slider", não possui comportamento, teclas nativas, foco estruturado ou acessibilidade garantida. Para um controlo deslizante, o ideal seria um elemento nativo ()

    Embora existam atributos ARIA (aria-valuenow, aria-valuemin, aria-valuemax), o elemento continua sem anúncio de alterações do valor ao leitor de ecrã, mecanismo de alteração do valor e indicação visual de foco adequada.

    Recomendação de melhoria
    Recomendamos implementar sliders nativos. Exemplos e sugestões de padrão acessível para slider:

  • issue#12 Componente dropdown com problemas de seleção com leitores de ecrã e teclado

    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

    Descrição do problema

    Foram identificadas falhas de acessibilidade no componente de dropdown que impedem o funcionamento correto com leitores de ecrã e tecnologias de apoio. O controlo não expõe semântica adequada nem estrutura ARIA conforme as boas práticas, o que faz com que os utilizadores não consigam perceber que se trata de um campo de seleção, nem navegar ou escolher opções de forma fiável.

    Componente dropdown nos visualizadores não é acessível por teclado

    Nas páginas dos visualizadores viSMOS, COScid e COSvgi no menu principal e secundário e secundário existem componentes dropdown que não são ativadas por teclado. As opções da lista são apenas visíveis com a interação com o rato, por exemplo na secção "Estatísticas" do menu lateral do visualizador COScid. (Figura 1)

    Image

    O problema decorre principalmente da ausência de um elemento focável com função clara de combobox ou da remoção do nativo da árvore de acessibilidade. Além disso, a lista de opções não está corretamente estruturada como listbox (com papéis de role="listbox" e role="option"), e os estados dinâmicos, como aria-expanded ou a indicação da opção selecionada, não são apresentados às tecnologias de apoio. Elementos “acessíveis” estão escondidos (.p-hidden-accessible) e não recebem foco real, enquanto o elemento visível não é o alvo de interação do teclado.

    Essa implementação incompleta faz com que o leitor de ecrã não anuncie a existência de subopções, não reconheça quando o menu é aberto e não permita selecionar datas, ou categorias de filtros usando teclado ou navegação assistiva. Este problema se repete na componente que está implementada em toda “Barra de ferramentas COScid", nas opções de primeiro nível “Processos”, “Pesquisa” e “Relatório”.

    Por exemplo na secção “Dinâmica” a seleção da unidade administrativa as subopções da lista não são anunciadas pelo leitor de ecrã e não é possível selecionar opção com a navegação por teclado, apenas com o rato. (Figura 2)

    Image

    No conjunto, estas falhas comprometem a perceção, a operabilidade e a robustez do componente, criando uma barreira crítica para utilizadores cegos ou com baixa visão que dependem exclusivamente da leitura de ecrã para interagir com campos de seleção.

    Recomendação de melhoria

    A recomendação é assegurar que o dropdown utilize um nativo (solução preferencial) ou, caso seja necessário manter um componente customizado, implementar o padrão WAI‑ARIA completo para combobox/listbox, garantindo papéis, estados e comportamentos coerentes com as expectativas das tecnologias de apoio.

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue#14 O foco não está limitado a modal

    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

    Notas Gerais

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

    Na página COSvgi, identificamos que as modais estão sem foco com o teclado. Mesmo com a modal aberta, é possível navegar por elementos interativos atrás da modal. Quando a modal está aberta é possível percorrer pelo conteúdo do website que se encontra abaixo do menu. Por exemplo na (Figura 1) o foco está no menu na opção “Ferramentas de medição”.

    Image

    Figura 1 - Visualizador COSvgi foco está direcionado a outros elementos externos a modal

    Recomendação de melhoria

    Recomendamos revisar todas as modais disponíveis no website para verificar que ao utilizar o teclado ou leitor de ecrã, o foco seja limitado apenas para o conteúdo da modal, nesse caso a área “Entrar COSvgi”. Enquanto a modal estiver aberta, a navegação por outras opções do website não deve ser possível.

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

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

Lista de evidências recolhidas:

  • issue#15 O botão 'Fechar’ está em outro idioma (Melhoria)

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

    O botão 'Fechar’ está em outro idioma

    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. (Figura 1)

    Image

    Figura 1- Modal com elementos interativos em inglês

    Recomendação

    É necessário rever todas as modais, pois é um comportamento recorrente em outras modais dos visualizadores o botão "Fechar" está em inglês. 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.

    A modal é fechada pelo mesmo botão acionador (IGCP)

    As modais devem apresentar um botão de fechar claramente visível e acessível através do teclado. Além disso, devem informar de forma clara o seu objetivo

    Para fechar a modal do menu, é possível através da tecla "ESC" no entanto é necessário regressar ao botão que a abriu. O mais crítico é que não existe um rótulo específico para ação de "Fechar" (Figura 2)

    Image

    Figura 2- Botão fechar não possui rótulo e não é visível pelos leitores de ecrã

    Se o rótulo do botão não for alterado para 'Fechar’ os utilizadores de leitores de ecrã podem não perceber que o botão também serve para fechar a modal.

    Recomendação
    Recomendamos que todas as modais incluam um botão Fechar, devidamente rotulado e claramente visível.

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

etiqueta: NOK

Lista de evidências recolhidas:

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

    etiqueta: chk 10 webetiqueta: NOKetiqueta: R 9.4

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

    Notas gerais

    • É útil que ao sair da modal, o utilizador seja posicionado no elemento que usou para invocar a modal. A modal é uma espécie de parêntesis, à conversa principal. É bom que o utilizador, depois do "parêntesis", possa voltar à conversa principal, no exato ponto onde a deixou.
    O foco é perdido quando a janela modal é fechada

    Garantir que o foco retorne ao botão que acionou a modal é uma prática que beneficia especialmente pessoas que utilizam navegação por teclado ou leitores de ecrã, ajudando-as a manter-se orientadas dentro da interface.

    Ao fechar uma modal, se o foco é perdido ou deslocado para um local inesperado, os utilizadores precisarão percorrer novamente a interface até chegar no local desejado para continuar a interação desejada.

    Na página do visualizador viSMOS existe uma modal, aberta através do menu lateral na opção CAOP (Carta Administrativa Oficial de Portugal). (Figura 1)

    Image

    Figura 1- Modal aberta sobre a informação do tema CAOP

    A modal ao ser fechada, possui foco direcionado para a barra superior no logotipo SMOS. (Figura 2)

    Image

    Figura 2- Modal fechada com foco perdido

    Recomendação
    Recomendamos reverem todas as páginas que apresentem esse tipo de componente para garantir que ao fechar a modal, o foco esteja no menu lateral que foi expandida.

Checklist Conteúdo

etiqueta: NOK

Nível de conformidade:

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

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue#29 Não existe um resumo do propósito do site na homepage

    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 slideshow, entre outros.

    Durante a análise verificou‑se que a Homepage do SMOS (Sistema de Monitorização da Ocupação do Solo) 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 sobre os serviços disponibilizados (Figura 1).

    Image

    Figura 1- Página inicial do website não possui um resumo do propósito

    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.

    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.

Requisito 1.2 - Os termos mais complexos têm uma definição agregada

etiqueta: NOK

Lista de evidências recolhidas:

  • issue#30 Não existe um glossário e há termos complexos sem definição

    etiqueta: chk conteúdoetiqueta: NOKetiqueta: R 1.2

    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 da SMOS(Sistema de Monitorização da Ocupação do Solo), apesar de existirem termos técnicos em várias páginas.

    Recomendações
    Recomenda-se a criação de uma página com um glossário que agregue os termos complexos e a sua definição. Além disso é necessário uma revisão dos termos complexos que existem, para que se complete o glossário com as suas definições. Pode ser utilizado como referência o glossário do site da Acessibilidade: https://www.acessibilidade.gov.pt/glossario/

    Existem termos complexos sem definição

    Na página do visualizador viSMOS existem siglas sem uma descrição curta associada. Por exemplo MIAEV, MACAT, OrtoSat e Ortofotos (Figura 1)

    Image

    Figura 1- Visualizador viSMOS com termos complexos sem definição agregada

    Na página de ajuda observamos que os termos complexos do visualizador COScid, algumas siglas possuem seus significados agregados por exemplo "Carta de Uso e Ocupação do Solo (COS)". (Figura 2)

    Image

    Figura 2- Página de ajuda com termos complexos que tornam o texto confuso

    No entanto, soa confuso e difícil associação que as siglas a seguir no texto são referentes as séries associadas ao ano de referência e versão correspondente. Recorte do texto:

    • COS1995v2, a COS2007v3, a COS2010v2, a COS2015v2 e a COS2018v2. A Série 2 (nova) integra a COS2018v3 e a COS2023v1

    O mesmo acontece com o visualizador COSvgi, que possui siglas associadas a checkboxs como por exemplo COSc e seus respetivos anos COSc2024, COSc2023 e outros. (Figura 3)

    Image

    Figura 3- Página do visualizador COSvgi com termos complexos sem definição agregada

    No entanto, não possuem definição agregada, como é o caso da checkbox “CAOP” que possui uma descrição complementar alternativa “Carta Administrativa Oficial de Portugal”.

    Recomendações
    Recomenda‑se a revisão da página de ajuda do visualizador COScid, de forma a tornar mais clara a apresentação das siglas, séries e versões associadas à Carta de Uso e Ocupação do Solo (COS). Embora a página já apresente alguns significados das siglas, a explicação atual não permite uma associação imediata entre os códigos apresentados (ex.: COS1995v2, COS2018v3, COS2023v1) e os respetivos anos, séries e versões. Essa falta de claridade torna o texto confuso e pode dificultar a compreensão por parte de utilizadores menos familiarizados com a nomenclatura técnica do sistema.

    • Adicionar exemplos concretos e explicação explícita sobre a estrutura das siglas, clarificando, por exemplo: “COS2018v3 corresponde à Carta de Ocupação do Solo de 2018, versão 3, integrada na Série 2 (nova).”
    • Quando for possível ter agregada uma definição das siglas como já foi feito em alguns casos dos visualizadores.
    • Evitar repetição textual desnecessária e reorganizar o conteúdo por blocos temáticos para melhorar a legibilidade.

    Implementar estas melhorias irá aumentar a compreensão da informação, facilitar a aprendizagem do sistema por novos utilizadores e promover uma experiência mais acessível e inclusiva

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

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

Lista de evidências recolhidas:

  • issue#32 Texto secundário de logotipo DGT(Diretório-geral do Território) pouco visível

    etiqueta: chk conteúdoetiqueta: melhoriaetiqueta: 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

    A informação secundária tem um tamanho de letra inferior a 10pt (equivalente a 13px)

    Na página inicial, verificou-se que o logotipo da entidade responsável pelo conteúdo do website apresenta baixa legibilidade. O texto secundário “DGT(Diretório-geral do Território)”, incluído no logotipo, encontra-se com dimensão tipográfica inferior a 10 pontos, tornando a sua leitura difícil ou mesmo impossível na visualização padrão. (Figura 1)

    Image

    Figura 1 - Logotipo DGT(Diretório-geral do Território) com informação secundária não legível

    Apenas é possível identificar o texto ao aplicar zoom no navegador, o que compromete a acessibilidade e o cumprimento das boas práticas de design inclusivo. Para garantir a legibilidade da informação secundária, deverá ser corrigido para um tamanho igual ou superior a 10pt (13px).

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue#38 O ícone do menu não têm um texto descritivo correto

    etiqueta: chk conteúdoetiqueta: melhoriaetiqueta: R 3.2

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

    Para ser mais claro onde se encontra o menu quando está colapsado, no caso de breakpoints de tablet e mobile, o ícone que representa o menu deve ser acompanhado de um texto descritivo (ex: “Menu”), porque não existe uma iconografia de menu universalmente reconhecida por todos os utilizadores.

    Ícone do menu com texto alternativo em inglês

    Verificou-se que o menu de mobile e tablet consiste apenas num ícone de “Menu Hambúrguer”, com texto alternativo em inglês aria-label="hamburger menu button" esta implementação dificulta a perceção para utilizadores pelo website ser em Português. (Figura 1)

    Image

    Figura 1- Menu com texto descritivo incorreto

    Recomendações
    Recomendamos adicionar o texto descritivo “Menu principal” ao ícone do menu. Um bom exemplo a considerar é o menu do selo https://selo.usabilidade.gov.pt/.

  • issue#37 A navegação principal do site está colapsada em desktop

    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.

    No caso de breakpoints superiores, normalmente considerados para desktop, devem estar imediatamente visíveis no ecrã pelo menos as opções de 1º nível porque, à partida, existe espaço para tal.

    No caso de breakpoints inferiores, normalmente considerados para tablet e mobile, o menu pode manter-se colapsado.

    O menu principal do site está colapsado na versão desktop, e só é possível expandi-lo a partir do botão “Menu hambúrguer” (Figura 1). Por isso, as opções de primeiro nível não são imediatamente visíveis para os utilizadores.

    Image

    Figura 1- Menu principal colapsado na versão desktop

    Recomendação
    As opções de 1º nível do menu devem estar sempre visíveis na página enquanto existir espaço.

Requisito 3.3 - As hiperligações de texto não devem ser diferenciadas apenas com base na cor

etiqueta: NOK

Lista de evidências recolhidas:

  • issue#39 Hiperligações do breadcrumb não se diferencia 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 de texto devem apresentar um contraste mínimo de 4,5:1 com a envolvente e uma representação visual complementar à cor - idealmente as hiperligações devem apresentar-se sublinhadas. As hiperligações em texto devem apresentar-se da mesma forma em todo o sítio Web.

    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.

    As hiperligações do breadcrumb não têm diferenciação do texto envolvente pois possuem a mesma cor e não possuem estilo aplicado no website para textos clicáveis, por exemplo com sublinhado, e podem ser confundidas com texto comum. (Figura 1)

    Image

    Figura 1- Hiperligação do breadcrumb não aparenta ser clicável, página Tecnologia do Espaço

    Na mesma página é apresentada a hiperligação “Inteligência Artificial” com um estilo de texto clicável, corretamente identificável como uma hiperligação.

    Recomendações

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

Requisito 4.1 - Os documentos longos têm um índice no topo com hiperligações internas para o mesmo

etiqueta: NOK

Lista de evidências recolhidas:

  • issue#40 Não existe índices no topo páginas longas

    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
    Os documentos com mais de três ecrãs de altura deverão ter a hierarquia de cabeçalhos espelhada num índice no topo da página com hiperligações internas para as respetivas secções e subsecções.

    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.

    Páginas longas sem índice no topo

    Durante análise identificamos páginas consideradas longas sem índice no topo, como por exemplo Cartografia de Base (Figura 1)

    Image

    Figura 1- Página Cartografia de Base considerada longa sem índice no topo

    Outras páginas com o mesmo problema:

    Exemplos da correta aplicação de índice no topo na página Visualizadores, Ajuda - viSMOS , Ajuda - COSvgi e Ajuda - COScid permitindo a leitura direcionada para o conteúdo com hiperligações para cada secção interna dessa página através de bookmarks.

    Recomendações

    Revisar todo o website para adicionar um índice em páginas longas com hiperligações para cada secção interna.

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue#41 Os conteúdos do site não se adaptam às diferentes resoluções de ecrãs

    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 sítio Web deve ser adaptável aos tamanhos mais comuns de visualização, adaptando-se a várias larguras de ecrã sem que surjam barras de varrimento horizontais.O layout do sítio Web deve ser adaptável aos tamanhos mais comuns de visualização, adaptando-se a várias larguras de ecrã sem que surjam barras de varrimento horizontais.

    É possível observar aa página Cartografia de Uso e Ocupação do Solo tabela não adapta-se a diferentes resoluções de ecrã. (Figura 1)

    Image

    Figura 1- Problemas de adaptação da tabela em diferentes resoluções

    Assim como o visualizador COScid o menu principal em versões para dispositivos móveis, não adapta-se a diferentes resoluções. (Figura 2)

    Image

    Figura 2- Menu do visualizador COScid não adapta-se a diferentes resoluções

    Recomendação

    Garantir que todo o layout das páginas indicadas e todo o website possua um comportamento responsive e adapta-se às diferentes resoluções de ecrã, sem necessidade de fazer varrimento horizontal que não haja conteúdo cortado.

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue#42 Existem elementos interativos acionados apenas com a passagem do rato (hover)

    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

    Notas gerais

    • Não devem existir elementos de interação, como hiperligações ou botões, que aparecem apenas quando se passa por cima com um dispositivo apontador. Este método de interação não está disponível em aparelhos com interação por toque.

    Na página inicial, no carrossel as setas interativas “previous” e “next” , só são ativados quando passamos o rato pelas imagens do carrossel. (Figura 1)

    Image

    Figura 1- Setas interativas do carrossel ativas apenas com hover

    Recomendação

    Garantir que os elementos interativos podem ser accionados através de outros tipos de interação como o teclado.

Requisito 5.2 - Os elementos interativos têm uma dimensão mínima de 44px CSS (44 pontos) (vertical e horizontal)

etiqueta: NOK

Lista de evidências recolhidas:

  • issue#43 Há elementos interativos com área clicável que não cumprem a dimensão mínima exigida (44px de altura e largura)

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

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

    Notas Gerais

    • De forma a assegurar que todos os elementos interativos são facilmente acionáveis por qualquer tipo de dispositivo apontador ou toque, estes devem ter a dimensão mínima de 44px CSS de altura e de largura.

    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, na página inicial o rodapé possui imagens-link como a logo do “PRR” com altura de 29.3px. (Figura 1)

    Image

    Figura 1- Rodapé do website com imagens-link e área clicável inferior ao recomendado

    Assim como as imagens-link adjacentes da “República Portuguesa” com 23,8px de altura, e do “Financiamento da União Europeia” com 19.3px de altura, não cumprem as dimensões mínimas necessárias para área mínima clicável.

    O mesmo problema acontece em elementos interativos das páginas dos visualizadores. Por exemplo viSMOS com o botão de "Ajuda" "Mostrar/Esconder detalhes" e "Checkbox" com dimensões inferiores ao recomendado. (Figura 2)

    Image

    Figura 2- Visualizador viSMOS, elementos interativos com área clicável inferior ao recomendado

    Na página do visualizador COSvgi o botão "Contacto", "Menu" e "Partilhar" possuem dimensões inferiores ao recomendado. (Figura 3)

    Image

    Figura 3- Visualizador COSvgi, elementos interativos com área clicável inferior ao recomendado

    Nas modais dos visualizadores, há botões com dimensões inferiores ao recomendado. Por exemplo, o visualizador COScid com a modal "Bem-vindo COScid - Série 2" o botão fechar com 32px de largura e 32px de altura (Figura 4)

    Image

    Figura 4- Visualizador COScid, elementos interativos com área clicável inferior ao recomendado

    Recomendações
    É necessário rever todos elementos interativos do website e devem garantir que possuem uma altura e largura igual ou superior a 44px de área clicável, mesmo que o ícone/imagem tenha um tamanho inferior.

Requisito 5.3 - Há apenas um botão de ação principal por página e o mesmo encontra-se destacado

etiqueta: NOK

Lista de evidências recolhidas:

  • issue#44 Existem botões principais e secundários com o mesmo estilo

    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

    • Deve existir apenas um botão de ação principal por página e o mesmo deve apresentar-se numa cor contrastante. Todos os outros botões devem ser considerados como secundários.

    Os botões de ação principal devem estar destacados numa página ou num bloco de informação para tornar mais perceptível o local onde os utilizadores devem clicar para realizar uma determinada tarefa.

    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 inicial do SMOS(Sistema de Monitorização da ocupação do Solo) o botão de ação principal “Saiba mais” possui o mesmo estilo do botão secundário "Visualizadores". (Figura 1)

    Image

    Figura 1- Página inicial com dois botões em destaque

    Além disso, a mesma cor de botões de ação principal é utilizada como cor de fundo de menus secundários.

    Image

    Figura 2- Menu secundário das páginas interiores com o mesmo estilo de botões de ações principais

    Esta falta de diferenciação faz com que todos os botões tenham o mesmo peso visual, dificultando que o utilizador identifique quais ações são prioritárias. 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.

    Recomendação
    Os botões principais devem ser estilizados de forma diferente dos botões de ação secundária. Pode-se também distinguir os botões através da forma (ex: preenchimento, delineamento, cantos arredondados).

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue#45 Há elementos interativos que 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 gráficos clicáveis devem ser percecionáveis como tal, através da forma, da cor ou do aparente volume. Ao mesmo tempo, suficientemente diferente de elementos não clicáveis para que não se confundam.

    • O contraste em elementos interativos deve ser de, no mínimo, 3:1 em relação a cor adjacente. Este contraste é aplicado a todos os estados dos elementos (normal, hover, focus, etc). Quando o elemento possui conteúdo em texto, o contraste deve ser de no mínimo, 4,5:1 com a cor de fundo.

    Botões que não aparentam ser clicáveis

    Na página do visualizador COSvgi o elemento interativo “Registar Participação”, apresentado na secção "COSvgi", não aparenta ser um botão no seu estado inicial. Visualmente, o componente surge apenas como texto simples, sem qualquer característica típica de elementos interativos, como fundo, borda ou contraste diferenciado. (Figura 1)

    Image

    Figura 1 -Visualizador COSvgi com botão que não aparenta ser clicável

    O estilo de botão só é aplicado após o utilizador passar o rato (hover) sobre o texto, momento em que o fundo azul e o botão se tornam visíveis. Antes disso, não há indicação clara de que o elemento é clicável.

    Recomendação de Melhoria

    Aplicar estilo de botão no estado inicial, ou seja, o elemento interativo deve apresentar aparência de botão antes de qualquer interação do utilizador.

    Existem elementos interativos que não possuem contraste

    O contraste em elementos interativos deve ser de, no mínimo, 3:1 em relação a cor adjacente. Este contraste é aplicado a todos os estados dos elementos (normal, hover, focus, etc). Quando o elemento possui conteúdo em texto, o contraste deve ser de no mínimo, 4,5:1 com a cor de fundo.

    A análise revela que no website existem elementos interativos que não possuem contraste suficiente o que dificulta reconhecê-los como elementos clicáveis. Por exemplo, na página do visualizador COSvgi, a combinação de cores do botão “Zoom in” possui um contraste (2,4:1) inferior ao recomendado. (Figura 2)

    Image

    Figura 2 - Elementos interativos do visualizador COSvgi não passam na avaliação de contraste com a ferramenta Color Contrast Analyser

    Na página do visualizador COScid, há elementos interativos com rácio de contraste inferior ao recomendado. Por exemplo, o menu “Ferramentas do mapa” com o botão “Zoom in” a cor de primeiro plano #FFFFFF em relação a cor de plano de fundo #9EC222 não passam na avaliação de contraste . O mesmo acontece nas combinações de cores do visualizador viSMOS. (Figura 3)

    Image

    Figura 2 - Elementos interativos do visualizador COScid não passam na avaliação de contraste com a ferramenta Color Contrast Analyser

    Recomendações
    Recomendamos a revisão de todo o website para verificação das cores dos vários estados dos elementos e garantir os valores mínimos de contraste em elementos interativos. Substituir cores que não passam na avaliação de contraste.

Checklist Transação

etiqueta: NOK

Nível de conformidade:

  • Checklist Transação: 41.7% (5/12)
    • Requisitos avaliados: 13 (1 N/A excluído, 12 aplicáveis)
    • Requisitos OK: 5
    • Requisitos NOK: 7
    • Requisitos N/A: 1

Requisito 1.1 - A sequência de tabulação entre campos segue a sequência de preenchimento

etiqueta: NOK

Lista de evidências recolhidas:

  • issue#48 Sequência de preenchimento incorreta nas etapas do formulário

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

    A sequência de tabulação entre campos segue a sequência de preenchimento.
    – ver requisito 1.1 na lista Transação

    Notas Gerais

    • A ordem de tabulação por entre os campos deve corresponder à sequência normal de preenchimento do formulário.
    Falta de feedback ao transitar entre etapas e foco incorreto do teclado

    Na página No formulário do menu ao passar da etapa 1 para a etapa 2 não há anúncio da mudança de estado. O leitor de ecrã não informa que o utilizador chegou à etapa “Dados”. Além disso, apresenta o foco incorreto na sequência de preenchimento, por exemplo na etapa 2 o foco do teclado não é colocado no campo de edição (“Nome de Grupo”), principal elemento a ser preenchido nesta etapa.
 Em vez disso ao pressionar TAB envia o utilizador para fora da área do formulário, o foco é transferido para os botões de “Ferramentas do mapa”. (Figura 1)

    Image

    O utilizador precisa aplicar Shift + TAB diversas vezes para regressar ao campo correto. Isto representa uma quebra de fluxo e causa significativa dificuldade para navegação acessível.

    Recomendações de melhoria

    • Corrigir o foco inicial da etapa

    Mover o foco programaticamente para o título da etapa quando esta é ativada. Assim que a etapa 2 é carregada, o foco deve ser colocado automaticamente no título "Dados" ou no campo de edição “Nome do Grupo”. Este comportamento reflete a intenção da interface e respeita a ordem lógica de preenchimento.

    • Fornecer feedback explícito ao entrar nas etapas

    Implementar mecanismos que informem o utilizador, de forma clara e acessível, que a etapa mudou. Como por exemplo utilizar aria-live="polite" no cabeçalho da área de etapas para anunciar:
“Etapa 2: Dados”

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

etiqueta: N/A

Lista de evidências recolhidas:

  • issue#47 Não foram identificados formulários com mais de 2 ecrãs no website

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

    Os formulários com mais de 2 ecrãs de altura devem ser distribuídos por várias páginas.
    – ver requisito 1.2 na lista Transação

    O requisito 1.2 da checklist de transação não se aplica ao website, uma vez que não foram identificados formulários logos com mais de 2 ecrãs de altura, pelo que este critério não aplica-se para a avaliação.

    Recomendamos atualizar requisito na checklist dos transação como "Não Aplicável -NA"

Requisito 2.3 - As legendas dos campos são breves e claras

etiqueta: NOK

Lista de evidências recolhidas:

  • issue#50 Existem campos do formulário sem legenda

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

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

    Notas Gerais

    Todos os campos devem ter uma legenda breve e clara associada, que descreva quais os tipos de dados que devem ser inseridos nesse mesmo campo.

    Foi identificado um campo de preenchimento sem legenda (label) na secção “Imprimir”, especificamente na opção “Escala de Saída” > “Livre”. É possível observar que o campo input utilizado para definir a escala não possui qualquer rótulo programático que permita aos leitores de ecrã identificar o seu propósito e não sendo imediatamente perceptível qual o tipo que deve ser inserido no campo. (Figura 1)

    Image

    Figura 1 - Visualizador COScid com análise da ferramenta ANDI na secção "Imprimir"

    Embora o campo esteja visualmente apresentado, a ausência de um nome acessível torna-o impossível de compreender para utilizadores que dependem de tecnologias de apoio.

    O mesmo acontece na secção “Pesquisa por Coordenadas”, existem campos sem nome acessível ou label associada. (Figura 2)

    Image

    Figura 2 - Visualizador COScid com análise da ferramenta ANDI na secção "Pesquisa por Coordenadas"

    Recomendação de Melhoria
    Adicionar legenda aos campos do menu principal dos visualizadores.

    Radio Buttons sem nome acessível e legenda atribuída

    Na página “Adicionar Temas” do Visualizador viSMOS, os radio buttons disponíveis não possuem nome acessível. (Figura 3)

    Image

    Figura 3 - Visualizador viSMOS com análise da ferramenta ANDI no formulário "Adicionar temas"

    Durante os testes com o leitor de ecrã NVDA verificou‑se que cada opção é anunciada apenas como “botão de opção não marcado 1 de 11”, “botão de opção marcado 2 de 11”, entre outras variações. Este comportamento evidencia que não existe qualquer rótulo associado semanticamente ao controlo. (Figura 4)

    Image

    Figura 4 - Visualizador viSMOS formulário "Adcionar Temas" com leitor de ecrã NVDA

    Embora visualmente cada opção apresente um texto associado (por exemplo: “WMS – Web Map Service”, “GeoJSON”, “DXF (v2000)”, “Grupo de Temas”), o NVDA não verbaliza estes nomes. Em vez disso, apresenta apenas mensagens genéricas como “botão” ou “botão de opção”, sem identificar o conteúdo da opção.

    Como resultado, um utilizador que recorre a tecnologias de apoio não consegue perceber o significado de cada escolha, comprometendo a compreensão e seleção correta das opções apresentadas.

    Recomendação de Melhoria
    Para garantir acessibilidade cada radio button deve possuir um nome acessível devidamente associado. Recomenda‑se:

    • A utilização de
    • A atribuição de um nome acessível através de aria-label ou aria-labelledby.

  • issue#49 A interação com o campo faz a legenda "Campo obrigatório" desaparecer

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

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

    Notas gerais

    • Todos os campos devem ter uma legenda breve e clara associada, que descreva quais os tipos de dados que devem ser inseridos nesse mesmo campo.

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

    No "Formulário de Contacto" da página COScid, é possível observar que a legenda dos campos "Nome", "Email", "Descrição" desaparece quando o utilizador interage com o campo para preencher os dados pedidos. (Figura 1)

    Image

    Figura 1 - Modal "Formulário de Contacto" com campos obrigatórios identificados

    Image

    Figura 2 - Modal "Formulário de Contacto" após interação legenda "Campos Obrigatórios" é desativada

    Recomendação
    Assegurar que legenda dos campos obrigatórios permanecem visíveis após o utilizador o interagir com os dados.

    • Recomendamos incluir o texto "Obrigatório" diretamente no label, como por exemplo na referência do Site do Selo.

    • Se a legenda estiver dentro do campo, pode ser reduzida para o topo ou para cima do campo (Figura 3): Se a legenda estiver dentro do campo, pode ser reduzida para o topo ou para cima do campo (Figura 3):

    Image

    Figura 3 - Sugestões de design de text field do Material Design

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue#51 Modal não informa campos obrigatórios

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

    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.

    Na modal "Entrar COSvgi" do visualizador COSvgi os campos "Utilizador / Email" e "Palavra-passe" não estão identificados quais os campos de preenchimento obrigatório. (Figura 1)

    Image

    Sendo assim, a identificação dos campos obrigatórios só aparece depois de submeter o formulário, como se fosse um erro. (Figura 2)

    Image

    Recomendações
    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 uma legenda no início do formulário que indique claramente o significado de *.

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue#52 Barra de progresso para os visualizadores não é acessível

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

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

    O sistema deve indicar o que está a acontecer quando determinadas ações são desencadeadas, principalmente quando o resultado não é imediato ou demora mais tempo do que é suposto.

    Ao aceder à página dos visualizadores, por exemplo o visualizador COSvgi após a ação “Aceito”, existe um período de carregamento até que o visualizador seja completamente disponibilizado. Durante este intervalo, é apresentada uma barra de progresso visível, permitindo aos utilizadores videntes perceber que o sistema está a processar a ação e que o carregamento poderá demorar mais do que o habitual. (Figura 1)

    Image

    Figura 1 - Barra de progresso para abertura do visualizador COSvgi não é anunciada pelo leitor de ecrã

    No entanto, para utilizadores de leitores de ecrã não é fornecida qualquer indicação sobre o que está a acontecer. Não existe anúncio de que o carregamento está em curso, nem informação de progresso, deixando estes utilizadores sem feedback sobre o estado da operação. Isto resulta numa experiência pouco previsível, podendo levar à perceção de falha ou bloqueio da interface.

    Recomendação
    Recomendamos apresentar uma indicação sobre o que está a acontecer de forma explícita e acessível durante o processo de carregamento do visualizador.

    • Apresentar uma mensagem acessível durante o carregamento, por exemplo: “A carregar o visualizador, por favor aguarde.” Esta mensagem deve ser exposta de forma programática, permitindo que tecnologias de apoio a anunciem corretamente.

    • Garantir acessibilidade da barra de progresso, caso seja mantida: A barra deve incluir texto alternativo e, sempre que possível, fornecer informação significativa, como o estado ou percentagem de carregamento. Exemplo: “Progresso: 45% concluído.”

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue#53 Ausência de mensagem para confirmação do sucesso ou erro da transação

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

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

    Notas Gerais

    • O sucesso de uma transação deve ser claramente comunicado ao utilizador através de uma mensagem de confirmação. O sucesso de uma transação deve ser claramente comunicado ao utilizador através de uma mensagem de confirmação.
    Visualizadores com problemas no menu "Adcionar Temas" sem confirmação na criação de categorias

    Durante análise, no menu do visualizador viSMOS possui um formulário para criação de categorias na secção "Adcionar Temas" composto por três etapas, esta opção também é disponível no visualizador COSvgi. A problemática identificada é que na etapa final do processo de criação da categoria, não é fornecido qualquer feedback acessível que indique ao utilizador que a operação foi concluída com sucesso.

    Embora visualmente surja uma nova categoria “Teste” no menu lateral com opções como editar, remover e um controlo deslizante esta informação não é anunciada pelo leitor de ecrã NVDA. (Figura 1)

    Image

    Figura 1 - Demonstração da navegação com NVDA pelo formulário "Adcionar Temas" e resultado da categoria criada "Teste"

    Como consequência, utilizadores cegos ou com baixa visão não conseguem perceber que a transação foi finalizada, que a nova categoria foi criada, nem que um novo elemento foi adicionado à interface.

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

    Observamos que as modais dos visualizadores COSvgi com o "Registo de Utilizador" e "Formulários de contacto" não exibem mensagens comunicando o sucesso / erro da operação para utilizadores.

    Em alguns casos, exibem apenas visualmente sem anunciar textos com leitores de ecrã. Por exemplo, o "Formulário de Contacto" visualmente exibe a mensagem em inglês “The website encountered an unexpected error. Please try again later.” Mas não informa o problema para utilizadores com tecnologias de apoio. (Figura 2)

    Image

    Figura 2 - Mensagem de erro em inglês e não anunciada automaticamente pelo leitor de ecrã NVDA

    Recomendação de melhoria

    Recomenda‑se que, após a criação da categoria, seja fornecido feedback acessível e imediato, garantindo que utilizadores de leitores de ecrã percebem claramente que a operação foi concluída. Para isso, deve ser apresentada uma mensagem de confirmação (ex.: “Categoria criada com sucesso”) e o foco deve ser reposicionado para a notificação ou para o novo elemento criado no menu lateral. Estas medidas asseguram perceção clara do final da transação e tornam o processo inclusivo e previsível.

    • É necessário rever todo o website para que os formulários possuam mensagens que comuniquem o resultado das operações através de mensagens de confirmação explícitas.

Requisito 4.1 - A informação já introduzida deve poder ser corrigida a qualquer momento

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

Lista de evidências recolhidas:

  • issue#57 Falta de indicação clara para remoção ou alteração de anexos no "Formulário de Contactos"

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

    A informação já introduzida deve poder ser corrigida a qualquer momento.
    – ver requisito 4.1 na lista Transação

    Notas Gerais:

    • Toda a informação já transmitida pelo utilizador numa sessão pode ser corrigida, em qualquer momento, antes da transação ser finalizada.

    Apesar de o website disponibilizar formulários em que os campos podem ser alterados livremente antes da submissão, a forma como alguns elementos funcionais são apresentados pode limitar a perceção do utilizador sobre essa possibilidade de correção.

    No Formulário de Contacto, o campo “Anexo” não indica explicitamente que o ficheiro selecionado pode ser removido ou substituído. A única forma de alterar o anexo é clicando novamente em “Escolher ficheiro”, comportamento que não é evidente nem comunicado ao utilizador. (Figura 1)

    Image

    Figura 1 - Anexar ficheiro no "Formulário de contacto"

    Apesar do website possuir formulários em que os campos de preenchimento podem ser alterados até a submissão. Melhorias podem ser feitas, por exemplo com o Formulário Contacto possui uma opção "Anexo" que não é explícito que é possível ser removido o ficheiro anexado. Apenas ao clicar novamente na opção "Escolher Ficheiro" que é possível alterar.

    Recomendações
    Recomenda‑se melhorar a clareza e a usabilidade do campo de anexos. Sugere‑se:

    • Adicionar uma indicação explícita de que o ficheiro pode ser removido ou substituído
    • Incluir um botão visível “Remover ficheiro” ou um ícone acessível com a função de eliminação.
    • Apresentar o nome do ficheiro acompanhado de uma ação clara de edição, garantindo que utilizadores com baixa literacia digital percebem que podem corrigir este campo antes da submissão.

Requisito 4.3 - As mensagens de erro são claramente identificadas junto aos campos de origem

etiqueta: NOK

Lista de evidências recolhidas:

  • issue#54 R 4.3 - Transação -Não são devolvidas mensagens de erro junto a cada campo do formulário

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

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

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

    Nas modais de "Formulário de contacto" dos visualizadores viSMOS, COSvgi e COScid verificou‑se que, ao submeter o formulário com erros de preenchimento, as mensagens de erro são apresentadas apenas no final da modal, ou seja, não estão programaticamente associadas aos respetivos campos que originaram o erro. Além disso, essas mensagens são genéricas, não informando sobre o formato de preenchimento do e-mail por exemplo. (Figura 1)

    Image

    Figura 1 - Visualizador COScid com mensagem de erro ao final da modal

    Como consequência, utilizadores de leitores de ecrã não recebem qualquer indicação sobre qual campo contém um erro, que tipo de erro ocorreu ou que informação é necessária para prosseguir. A validação ocorre apenas após a submissão, e a ausência de associação semântica impede a identificação clara dos erros, resultando numa experiência inacessível e numa falha na orientação ao utilizador.

    O mesmo problema também acontece na modal "Entrar - COSvgi" em que as mensagens e erro não estão associados aos respetivos campos. (Figura 2)

    Image

    Figura 2 - Visualizador COSvgi com mensagem de não atribuídas aos respetivos campos de preenchimento

    Recomendações
    Recomendamos a revisão dos formulários no website, 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 erros de preenchimento em seus respetivos campos de preenchimento.
    • Indicar qual o formato correto de preenchimento de e-mail (ex.: formato esperado).

Requisito 4.4 - As mensagens de erro devem mostrar os passos concretos para a resolução dos mesmos

etiqueta: NOK

Lista de evidências recolhidas:

  • issue#56 Não são devolvidas mensagens de erro para leitor de ecrã

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

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

    Os campos dos formulários devem devolver mensagens de erros explícitas sobre como resolver o problema identificado em cada campo. Essas mensagens devem ser comunicadas visualmente e pelo leitor de ecrã.

    Na página Formulário de Contacto ao preencher o formulário com campos vazios e submetê-lo, o foco do leitor de ecrã não é direcionado para o campo que contém o erro, mas sim para o final da página. (Figura 1)

    Image

    Figura 1 - Foco do formulário não é direcionado para mensagens de erro quando é feita a submissão do formulário

    Este comportamento impede que utilizadores com tecnologias de apoio percebam rapidamente qual campo está incorreto ou por preencher, causando confusão, frustração e quebra no fluxo da interação.

    Apesar de a interface destacar visualmente os erros com bordas vermelhas e os erros estar associados aos campos, essa indicação não é suficiente nem acessível para utilizadores cegos ou com baixa visão, uma vez que as mensagens de erro não estão associadas programaticamente aos respetivos campos. Assim, o leitor de ecrã não anuncia a existência do erro nem orienta o utilizador sobre como corrigi-lo.

    Recomendação de Melhoria
    Recomenda‑se associar cada mensagem de erro diretamente ao respetivo campo através de mecanismos como aria-describedby, garantindo que leitores de ecrã anunciem automaticamente o erro e sua localização.
    Além disso, após a validação, o foco deve ser encaminhado para o primeiro campo com erro, permitindo ao utilizador compreender de imediato o que necessita ser corrigido. Estas medidas asseguram uma experiência inclusiva, intuitiva

  • issue#55 Modais com problemas nas mensagens de erro com leitor de ecrã

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

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

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

    A página dos dos visualizadores possuem as modais “Registo de Utilizador” e “Formulário de Contacto”, as quais verificou‑se que as mensagens de erro apresentadas após a submissão de formulários incompletos ou com dados inválidos não cumprem o presente requisito.

    Por exemplo na secção "Registo de Utilizador" na página do visualizador COSvgi, quando o utilizador tenta submeter o formulário com campos obrigatórios vazios, a interface apresenta apenas um contorno vermelho nos campos com erro e texto genérico “Campo obrigatório” junto de cada campo. (Figura 1)

    Image

    Figura 1 - Visualizador COSvgi mensagens de erro não são anunciadas pelo leitor de ecrã NVDA na modal "Registo de Utilizador"

    Embora estas indicações sejam visíveis, não estão programaticamente associadas aos respetivos inputs, impedindo que leitores de ecrã anunciem corretamente a ocorrência do erro ou identifiquem qual campo necessita de intervenção. Como resultado, utilizadores cegos ou com baixa visão não recebem feedback imediato sobre a existência de erros, informação clara sobre a causa do problema e instruções sobre o que falta preencher ou como o corrigir.

    Adicionalmente, na página do visualizador viSMOS no "Formulário de Contacto" ao inserir um e-mail num formato inválido, a mensagem genérica "Campo de preenchimento obrigatório" esta ensagens de erro não é explícita e não oferece qualquer tipo de sugestão ou ajuda no preenchimento. (Figura 2)

    Image

    Figura 2 - Visualizador viSMOS mensagens de erro genéricas do visualizador

    Ainda assim se o utilizador seguir com o preenchimento, e submeter o formulário com algum erro de preenchimento a mensagem “Formato de email incorreto” surge apenas após a submissão e, novamente, de forma descontextualizada, não fornece instruções concretas (ex.: indicar o formato esperado ou um exemplo válido) e sem associação ao campo correspondente. (Firgura 3)

    Image

    Figura 3 - Visualizador viSMOS mensagens de erro não fornecem instruções concretas

    Recomendações de melhoria

    Recomendamos a revisão dos formulários do website, para garantir que as mensagens de erro devolvidas junto aos campos sejam úteis na resolução do problema e identifiquem os passos necessários para o resolver.

    • Indicar de forma objetiva o que está errado e como corrigir. Com mensagens por exemplo: “Preencha este campo.” e “Introduza um email válido no formato (Ex: nome@dominio.pt).”

    Além disso, as mensagens devem ser anunciadas automaticamente para garantir que utilizadores de leitores de ecrã recebem feedback imediato e compreendem os passos necessários para concluir o formulário.

Outras violações

etiqueta: NOK

Lista de evidências recolhidas:

  • issue#68 Outras violações - Botões sem nomes acessíveis ou apenas com title

    etiqueta: NOKetiqueta: outras violações
    Descrição do problema

    Durante a análise foram identificados nas páginas dos visualizadores vários botões que não possuem um nome acessível adequado. Esta situação compromete a experiência de utilizadores que dependem de tecnologias de apoio, como leitores de ecrã, que necessitam de um rótulo programático claro para comunicar a função de cada elemento interativo.

    Por exemplo, na página viSMOS a secção “Ferramenta de Desenho” existem botões totalmente sem identificação (Figura 1)

    Image

    Figura 1- Visualizador viSMOS com navegação pelo NVDA

    Na página do visualizador COScid existem botões que recorrem apenas ao atributo title para transmitir a sua função. (Figura 2)

    Image

    Figura 2- Botões do visualizador COScid apenas com title atribuído

    A utilização exclusiva do atributo title não é suficiente para garantir acessibilidade, uma vez que o seu suporte é inconsistente entre navegadores e leitores de ecrã pois não é acionado adequadamente por navegação via teclado e dispositivos móveis (ausência de hover). Além de não ser facilmente percecionado por utilizadores com dificuldades motoras ou cognitivas. A ausência de um nome acessível dificulta a compreensão da interface, podendo impedir a execução de ações essenciais.

    Na página do visualizador COSvgi, identificamos que existem botões sem nome acessível, sendo assim ao percorrer cada botão com as teclas de navegação do teclado o leitor de ecrã NVDA anuncia apenas o texto “botão”. (Figura 3)

    Image

    Figura 3- Visualizador COSvgi com navegação pelo NVDA com teclas direcionais

    Quando a navegação é feita com shift+TAB é possível reconhecer alguns botões através do nome acessível atribuído ao title. No entanto, ainda apresentam inconsistências nos nomes acessíveis por exemplo com os botões “Zoom in” “Zoom out” e “Full-screen”, que o leitor de ecrã apenas anuncia o texto “botão” com os símbolos +, - e ⤢ (Figura 4)

    Image

    Figura 4- Visualizador COSvgi com nomes acessíveis incorretos ou ausentes

    Além disso o botão “Ampliar” possui texto alternativo em inglês title="Toggle full-screen" (Figura 5)

    Image

    Figura 5- Ferramentas do Mapa, botão com nome acessível em inglês

    Recomendações

    Recomenda-se garantir que todos botões possuam um nome acessível adequado e no idioma do website. Em casos de botões compostos apenas por ícones ou sem texto visível, deve-se utilizar o atributo aria-label para fornecer uma descrição clara e programaticamente determinável da ação executada. O uso de aria-label ou aria-labelledby assegura compatibilidade consistente com tecnologias assistivas e conformidade com as diretrizes de acessibilidade

  • issue#67 Outras violações - Scroll da página para o topo ao clicar em imagens

    etiqueta: melhoriaetiqueta: outras violações
    Descrição do problema

    Na página Produtos Cartográficos as imagens dos produtos são apresentadas como elementos interativos e clicáveis com alteração do cursor. Contudo, ao serem selecionadas o utilizador é reposicionado para o topo da página sem que ocorra navegação para um novo conteúdo nem seja fornecida qualquer indicação do resultado da ação.

    A inspeção do DOM em runtime demonstra que não existe um href válido associado às imagens. Sendo o comportamento desencadeado por manipuladores de clique em JavaScript que produzem uma mudança de contexto inesperada. (Figura 1)

    Image

    Figura 1- Imagem atribuída a um href sem link com manipulação do clique via JavaScript

    Esta implementação compromete a previsibilidade da navegação, pode causar perda de contexto e não comunica adequadamente o propósito do componente às tecnologias assistivas.

    Recomendação de melhoria
    Os elementos devem possuir semântica e comportamento coerentes com a sua função. Caso a intenção seja navegar, a imagem deve estar contida num link com destino real e nome acessível que identifique claramente a ação. Caso execute uma funcionalidade dinâmica, deve ser implementada como botão, com papel programático adequado e sem provocar reposicionamento automático da página. Em qualquer cenário, o resultado da ativação deve ser previsível e alinhado com as expectativas do utilizador, evitando mudanças de contexto inesperadas.

  • issue#66 Outras violações - Problemas com ReCAPTHA inacessíveis

    etiqueta: NOKetiqueta: outras violações
    Descrição do problema
    • Foram identificadas falhas de acessibilidade no reCAPTCHA utilizado nos formulários dos visualizadores, comprometendo a validação por parte de utilizadores que dependem da alternativa áudio. Em alguns casos, o áudio não é reproduzido, e noutros é disponibilizado apenas em inglês, divergindo do idioma do website e criando uma barreira adicional. Estas limitações impedem que utilizadores com deficiência visual consigam completar a verificação e concluir a submissão do formulário.

    Nas modais do visualizador COScid, o reCAPTCHA apresenta falhas de acessibilidade na sua versão áudio, ao pressionar o botão “Reproduzir”, nenhum áudio é emitido, impossibilitando que utilizadores que dependem desta alternativa realizem a verificação. (Figura 1)

    Image

    Figura 1 - "Formulário de contacto" da modal dos visualizadores com problema de reprodução do áudio no reCAPTCHA

    Além disso, no Formulário de Contacto do website, o áudio do reCAPTCHA é disponibilizado apenas em inglês, apesar de o site estar implementado em português. Esta inconsistência linguística cria uma barreira adicional para utilizadores que não compreendem inglês, dificultando ou impedindo a conclusão da verificação. (Figura 2)

    Image

    Figura 2 - Formulário de contacto com reprodução do aúdio em inglês no reCAPTCHA

    Estas falhas comprometem o preenchimento dos formulários por parte de pessoas com deficiência visual e não cumprem boas práticas de acessibilidade recomendadas para mecanismos de verificação.

    Recomendação de Melhoria

    Recomenda‑se garantir que a alternativa de áudio do reCAPTCHA funcione corretamente em todos os visualizadores e que esteja disponível na mesma língua do website (português).

    Adicionalmente, sempre que o reCAPTCHA falhar ou não puder ser acionado, deve ser disponibilizado um método alternativo de verificação acessível, como um desafio simplificado, validação por checkbox acessível ou mecanismo sem barreiras auditivas ou visuais. Estas melhorias asseguram equidade de acesso, permitindo que utilizadores de tecnologias de apoio consigam submeter formulários sem impedimentos

  • issue#65 Outras violações - Botão de Menu Hambúrguer com nome acessível em Inglês

    etiqueta: melhoriaetiqueta: outras violações
    Descrição do problema

    Durante a análise da página inicial foi identificado que o botão de menu hambúrguer apresenta um nome acessível em inglês aria-label="hamburger menu button",no entanto o website está configurado para o idioma português. (Figura 1)

    Image

    Figura 1- Botão do menu hamburguer anunciado pelo leitor de ecrã NVDA com nome acessível em inglês

    Esta inconsistência linguística afeta a experiência de utilizadores que dependem de leitores de ecrã ou outras tecnologias de apoio, uma vez que o conteúdo anunciado não corresponde à língua definida na página. Além de quebrar a coerência linguística, esta falha pode gerar confusão, dificultar a compreensão e comprometer a conformidade com as diretrizes de acessibilidade.

    Recomendação de Melhoria

    Recomenda‑se que o botão de menu hambúrguer utilize um nome acessível no mesmo idioma do site, garantindo consistência e clareza. Para isso, devem ser aplicadas boas práticas de acessibilidade, tais como:

    • Definir um rótulo em português através de aria-label ou aria-labelledby

    • Garantir que todos os estados (por exemplo, “Abrir menu” / “Fechar menu”) também sejam disponibilizados em português, sempre refletindo a ação atual do botão.

    • Rever o design system ou biblioteca de componentes para assegurar que todos os botões de ícone têm nomes acessíveis corretamente localizados.

    A implementação desta melhoria assegurará maior clareza para utilizadores com tecnologias de apoio, reforçará a consistência linguística da interface.

Significado das etiquetas utilizadas

  • etiqueta: OK - status OK
  • etiqueta: melhoria - status OK, mas pode melhorar
  • etiqueta: NOK - status Not OK
  • etiqueta: N/A - status Não Aplicável
  • etiqueta: chk10 web - checklist 10 Aspetos críticos de acessibilidade funcional
  • etiqueta: chk conteúdo - checklist Conteúdo
  • etiqueta: chk transação - checklist Transação
  • etiqueta: outras violações - permite construir o subcapítulo "Outras violações", o qual integra o capítulo "Avaliações manuais"
  • etiqueta: dec a11y - permite construir o capítulo "Declaração de acessibilidade e usabilidade"
  • etiqueta: av auto - permite construir o capítulo "Avaliação automática"
  • etiqueta: testes usabilidade - permite construir o capítulo "Testes de usabilidade"