Relatório Avaliação de Candidatura
Portal da Defesa Nacional

Introdução

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

Estado das avaliações efetuadas
Tipo de avaliaçãoEstado
Avaliação Automáticaetiqueta: NOK
Avaliação Manualetiqueta: NOK

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

Níveis de conformidade das avaliações manuais
ChecklistConformidade alcançadaResultado
10 aspetos51.9% (14/27)etiqueta: Não passa
Conteúdo35.3% (6/17)etiqueta: Não passa
Transação36.4% (4/11)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: 51.9% (14/27)
    • Requisitos avaliados: 27 (27 aplicáveis)
    • Requisitos OK: 14
    • Requisitos NOK: 13

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 #23 O tipo de lista utilizado para estruturar o rodapé é inapropriado

    etiqueta: chk 10 webetiqueta: R 1.1etiqueta: NOK

    O uso de listas ordenadas ol li é adequado quando a ordem dos elementos é relevante, como em instruções, passos sequenciais ou processos que devem ser seguidos numa determinada sequência.

    No rodapé, embora exista um conjunto de links relacionados entre si, cada opção é independente e não segue uma ordem lógica obrigatória. No entanto, está a ser utilizada uma lista ordenada para estruturar estes elementos, o que não é apropriado:

    Image

    URLs

    Sugestão de correção

    • Alterar as duas listas apresentadas no rodapé para listas não ordenadas, utilizando as tags ul e li do HTML.

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 #24 Está sendo utilizado atributos inapropriados no menu

    etiqueta: chk 10 webetiqueta: R 1.2etiqueta: NOK

    O atributo aria-haspopup é comumente utilizado na construção de menus do tipo aplicação. O menu principal do website corresponde a um menu de navegação e não a um menu de aplicação e verifica-se que está sendo utilizado o atributo aria-haspopup no menu:

    Image

    URLs

    Sugestão de correção

    • Remover o aria-haspopup do menu desktop e mobile. A informação de que a opcão está aberta ou fechada deve ser transmitida pelo atributo aria-expanded.

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

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

Lista de evidências recolhidas:

  • issue #25 As imagens-link do menu principal têm texto alternativo apropriado

    etiqueta: chk 10 webetiqueta: melhoriaetiqueta: R 1.3

    O critério está a ser cumprido: a sinalética das opções do menu (▾), e dos ícones de pesquisa e das redes sociais, apresentam texto alternativo apropriado através do atributo aria-label. No entanto, verifica‑se que esse mesmo texto alternativo está duplicado no atributo title, o que gera uma redundância desnecessária:

    URLs

    Sugestão de correção

    • O atributo title deve ser utilizado apenas quando acrescenta informação complementar ao texto alternativo já fornecido através do aria-label. Neste caso, recomenda‑se remover o atributo title das opções do menu.

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 #46 Cabeçalhos marcados com <p>

    etiqueta: chk 10 webetiqueta: NOKetiqueta: R 2.2

    Evidências

    Foram identificados elementos que funcionam visualmente como cabeçalhos, mas que se encontram marcados incorretamente com <p> em vez de elementos de cabeçalho semanticamente adequados.

    Image

    Figura 1 - Texto “Atribuições do Ministério da Defesa Nacional” marcado com <p> em vez de um elemento de cabeçalho.

    URLs a verificar:
    https://www.defesa.gov.pt/pt/defesa/Paginas/mdn.aspx

    Recomendações

    • Substituir o elemento <p> utilizado como título de secção por um elemento de cabeçalho semanticamente adequado.
    • Neste caso específico, recomenda-se a utilização de <h2>, de acordo com a hierarquia da página.

  • issue #30 Cabeçalhos vazios

    etiqueta: chk 10 webetiqueta: NOKetiqueta: R 2.2

    Evidências

    Foi identificado um cabeçalho vazio.

    Image

    Figura 1 - Cabeçalho vazio .

    URLs a verificar:

    https://www.defesa.gov.pt/pt/pdefesa/mi

    Recomendações

    • Remover o cabeçalho vazio.

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 #47 Campo de pesquisa com label não acessível (placeholder a substituir a label)

    etiqueta: chk 10 webetiqueta: NOKetiqueta: R 4.1

    Evidências

    O campo de pesquisa presente no cabeçalho do site possui um elemento <label> associado ao input através do atributo for="tbPesquisa", contudo esta etiqueta encontra-se oculta através de display: none, deixando de estar disponível para todos os agentes de utilizador.

    Nestas circunstâncias verificam-se dois problemas:

    • o leitor de ecrã poderá não anunciar corretamente o propósito do campo, ficando o utilizador sem contexto claro sobre a sua função;
    • deixa de ser possível aumentar a área de clique através da etiqueta, impedindo que o utilizador possa focar o campo ao clicar sobre a respetiva label, o que pode dificultar a interação para pessoas com limitações motoras.

    Verifica-se ainda que o campo depende visualmente do texto placeholder="Pesquisar..." para identificação. No entanto, o placeholder desaparece quando o utilizador começa a escrever, não devendo substituir uma etiqueta persistente do campo.

    Image

    Figura 1 - Campo de pesquisa no cabeçalho do site com label oculto (display:none) e utilização de placeholder como único meio de identificação do campo

    URL a verificar

    Recomendações

    Recomenda-se garantir que o campo de pesquisa possui uma etiqueta corretamente associada ao campo através do elemento <label>.

    • Garantir a existência de um elemento <label> associado explicitamente ao campo através de for e id;
    • Evitar ocultar etiquetas necessárias à identificação dos campos com display: none;
    • Garantir que a etiqueta permanece disponível e utilizável, permitindo focar o campo ao clicar sobre ela;
    • Utilizar o placeholder apenas como texto de apoio ao preenchimento e não como substituto da etiqueta do campo.

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 #76 Não é possível identificar campos obrigatórios nos formulários em PDF

    etiqueta: chk 10 webetiqueta: R 4.2etiqueta: NOK

    Evidências

    Verificámos que, no Formulário de Pedido de Pedido de Visita, presente na página Portal da Defesa Nacional, não é possível reconhecer os campos de preenchimento obrigatório. Esta informação não é passada quer visualmente quer para os leitores de ecrã.

    Image

    Análise do Formulário de Pedido de Pedido de Visita, presente na página Portal da Defesa Nacional, no browser através do leitor de ecrã NVDA.

    Recomendações

    Uma solução mais acessível seria disponibilizar os formulários diretamente no site, em vez de em formato PDF. Nos formulários web, os campos obrigatórios devem incluir o atributo required para serem identificados pelas tecnologias de apoio como obrigatórios. Adicionalmente, deve também ser apresentada uma indicação visual clara junto ao rótulo — por exemplo, “(Campo obrigatório)” — para que todos os utilizadores consigam identificar facilmente os campos que têm obrigatoriamente de preencher.

  • issue #57 Campos obrigatórios sem utilização do atributo HTML nativo required

    etiqueta: chk 10 webetiqueta: R 4.2etiqueta: melhoria

    Evidências

    Verificou-se que os campos obrigatórios do formulário de contacto são identificados programaticamente através do atributo aria-required="true" e visualmente através da indicação textual “(obrigatório)”.

    Contudo, não é utilizado o atributo HTML nativo required nos respetivos campos de formulário.

    Embora aria-required="true" permita expor informação de obrigatoriedade a tecnologias de apoio, a utilização exclusiva deste atributo reduz a robustez da implementação, uma vez que o atributo nativo required fornece suporte adicional ao nível do navegador, validação do formulário e interoperabilidade entre tecnologias de apoio.

    Image

    Figura 1 – Campo obrigatório identificado com aria-required="true", sem utilização do atributo HTML nativo required

    URL a verificar

    Recomendações

    • Utilizar o atributo HTML nativo required em todos os campos obrigatórios;
    • Evitar depender exclusivamente de aria-required="true" quando existe alternativa HTML semântica nativa;
    • Manter a identificação visual dos campos obrigatórios;
    • Validar o comportamento com leitores de ecrã e validação nativa do navegador.

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 #63 As mensagens de erro não são apresentadas de forma consistente junto aos campos de origem

    etiqueta: chk 10 webetiqueta: NOKetiqueta: R 4.3

    Evidências

    No formulário de contacto, após submissão inválida, são apresentadas mensagens de erro na proximidade dos campos obrigatórios (Nome, Email, Assunto e Mensagem).

    Contudo, verifica-se que a apresentação destas mensagens não é totalmente consistente entre os diferentes campos, encontrando-se distribuídas por diferentes elementos e containers, o que pode dificultar a sua rápida identificação e leitura durante a navegação pelo formulário.

    Embora as mensagens sejam apresentadas visualmente junto aos campos, a sua organização pode dificultar a perceção clara da relação entre erro e campo correspondente, sobretudo quando se utiliza navegação sequencial ou tecnologias de apoio.

    Image

    Figura 1 - Campo “Mensagem” sem associação programática à respetiva mensagem de erro

    URL a verificar

    Recomendações

    • Garantir que todas as mensagens de erro são apresentadas de forma consistente na vizinhança dos respetivos campos;
    • Assegurar uma proximidade visual clara entre cada campo e a respetiva mensagem de erro;
    • Garantir que as mensagens são breves, claras e facilmente localizáveis durante a navegação pelo formulário;
    • Validar a experiência com tecnologias de apoio, assegurando que as mensagens são facilmente identificáveis durante a navegação pelos campos.

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

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

Lista de evidências recolhidas:

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #10 Imagem link têm um equivalente alternativo incorreto

    etiqueta: chk 10 webetiqueta: NOKetiqueta: R 5.3

    Evidências

    O nome acessível do icone de Partilha esta definido por aria-label="Links" não comunica corretamente a função do elemento, e o atributo title="Partilhar" introduz redundância e inconsistência. Recomenda-se utilizar um botão com nome acessível claro e específico para a ação de partilha.

    Image

    Verifica-se que as imagens-link das redes sociais possuem atributo title para fornecer o seu nome acessível juntamente com aria-label. Nesse caso o equivalente alternativo deve ser disponibilizado no mecanismo acessível principal apenas através do aria-label. Recomenda-se remover o title.

    Image

    A imagem-link “Denúncia” tem equivalente alternativo através do atributo alt, mas o texto não é totalmente adequado, porque mistura a descrição do destino com uma formulação pouco clara. O texto alternativo nas imagens link deve identificar claramente o destino da hiperligação. Por exemplo: alt="Portal de denúncias de presumíveis atos de corrupção, abre em novo separador".
    Também foi verificado que ao navegar com o leitor de ecrã, o equivalente alternativo aparece repetido.

    Image

    Os links associados às publicações são apresentados apenas através de um emoji de hiperligação, sem um nome acessível descritivo. Uma vez que o ícone é meramente visual e não existe uma alternativa textual equivalente, as pessoas que utilizam tecnologias de apoio não conseguem perceber qual é o destino ou a finalidade da hiperligação.

    Image

    Ao navegar pelos cards de documentos da homepage, a tecnologia de apoio deve anunciar que o documento a ser acessado é um pdf. Nesse caso deve ser removido o aria-label do elemento <a> e o ícone de PDF deve receber um nome acessível descritivo no elemento que o representa semanticamente, neste caso o div, por exemplo aria-label="Ficheiro PDF".

    Image

    O texto alternativo das imagens que abrem a janela modal está definido como “Fazer zoom da imagem”, o que não descreve o conteúdo visual nem permite compreender a finalidade da imagem. Recomenda-se alterar o texto alternativo para uma descrição mais clara e contextual.
    Além disso, quando a imagem é apresentada em tamanho ampliado dentro da janela modal, esta deve também ter um texto alternativo adequado, que descreva o conteúdo visual da imagem ampliada.

    Image Image

    URL:

    https://www.defesa.gov.pt/pt
    https://www.defesa.gov.pt/pt/comunicacao/agenda/Paginas/default.aspx
    https://www.defesa.gov.pt/pt/adefesaeeu/cd/Paginas/default.aspx
    https://www.defesa.gov.pt/pt/pdefesa/ac/pub/biblioteca/Paginas/default.aspx
    https://www.defesa.gov.pt/pt/pdefesa/cplp/Paginas/default.aspx

    Recomendações

    • Garantir que o texto alternativo descreve o destino da hiperligação, e não apenas a imagem visual.
    • Para a imagem link “Denúncia”: é necessário verificar se existe algum script no website que esta a transmitir alguma informação para o leitor de ecrã, pois o texto esta a ser lido duas vezes.
    • Manter apenas uma fonte de nome acessível para a imagem-link, preferencialmente o alt da própria imagem, e rever o texto para ser claro, correto e não repetitivo.

    Para o icone de Partilha:

    • Usar um nome acessível claro, por exemplo: aria-label="Partilhar"
    • Remover o title

    Para o ícone PDF:

    • Remover o aria-label do elemento <a>
    • O nome acessível pode ser aplicado ao <div> envolvente do ícone., por exemplo aria-label="Ficheiro PDF".

    Para as imagens da modal:

    • Alterar o texto alternativo para "Ampliar folheto do prêmio".
    • Inserir texto alternativo descrevendo o conteúdo visual quando a imagem está ampliada.
      Observação: Não seria necessário utilizar uma modal para estas imagens; o ideal seria tratar o elemento como uma imagem decorativa. Caso optem por manter a modal, os erros identificados devem ser corrigidos.

Requisito 7.1 - Deve ser possível ativar os botões de controlo do leitor quer com o rato quer com o teclado

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

Lista de evidências recolhidas:

  • issue #40 Vídeos de dimensão pequena e sem possibilidade de tela cheia

    etiqueta: chk 10 webetiqueta: melhoriaetiqueta: R 7.1

    Deve ser possível ativar os botões de controlo do leitor quer com o rato quer com o teclado.
    – ver requisito 7.1 na lista 10 aspetos

    Evidências:

    Existem players de vídeo incorporados no website com dimensões reduzidas e sem funcionalidade de visualização em ecrã inteiro. Embora o botão de ecrã inteiro esteja presente, este não se encontra operacional. Esta limitação pode comprometer a perceção e compreensão dos conteúdos multimédia, especialmente por utilizadores com incapacidades visuais ou baixa visão, dificultando um acesso pleno e equitativo à informação.

    Image Image

    URL's a verificar:

    Recomendações:

    • Permitir que o botão de tela cheia funcione corretamente
    • Disponibilizar opção de ecrã inteiro
    • Permitir redimensionamento responsivo do player

Requisito 7.2 - O vídeo ou o áudio deve conter preferencialmente legendas fechadas sincronizadas. Caso não seja possível, no mínimo, deve disponibilizar-se uma transcrição textual

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #32 Conteúdo visual sem audiodescrição

    etiqueta: chk 10 webetiqueta: NOKetiqueta: R 7.2

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

    Evidências:

    Existem players multimédia que apresentam mensagens através de elementos visuais, sem disponibilizar audiodescrição. Em vídeos com música de fundo ou sem narração, onde o conteúdo relevante é transmitido apenas por ações visuais, as pessoas com incapacidade visual podem não conseguir compreender a mensagem apresentada.

    Para garantir acessibilidade, todos os conteúdos visuais essenciais devem ser acompanhados por audiodescrição ou por uma alternativa equivalente que permita compreender integralmente a informação transmitida no vídeo.

    Image

    Imagem de vídeo com uma introdução com elementos visuais e música de fundo. Disponível em: https://www.defesa.gov.pt/pt/pdefesa/esdp/Paginas/default.aspx

    URL's a verificar:

    Recomendações:

    • Incluir audiodescrição sempre que existam informações relevantes comunicadas apenas visualmente.
    • Validar os conteúdos multimédia com utilizadores de tecnologias de apoio, como leitores de ecrã.
    • Assegurar que os controlos do player permitem ativar/desativar faixas de audiodescrição de forma acessível.
    • Disponibilizar uma versão alternativa do vídeo com audiodescrição integrada, quando necessário.
    • Garantir que textos apresentados no ecrã sejam também narrados em áudio.

  • issue #31 Os players não têm legendas audiodescritivas

    etiqueta: chk 10 webetiqueta: NOKetiqueta: R 7.2

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

    Evidências:

    Alguns players não têm legendas, os restantes players no website usam as legendas automáticas do youtube, é recomendado que estas sejam substituídas por legendas audiodescritivas.

    Image

    URL's a verificar:

    Recomendações:

    Recomendamos que seja incluído uma legenda para cada vídeo, caso a legenda gerada automaticamente esteja boa ela pode ser reaproveitada para gerar uma nova transcrição do conteúdo.

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 #75 Links da agenda possuem nomes acessíveis pouco descritivos

    etiqueta: chk 10 webetiqueta: NOKetiqueta: R 8.3

    Evidências

    Na secção Agenda, os links para os eventos encontram-se associados apenas ao bloco visual da data do evento (dia e mês), sendo o título apresentado fora do elemento .

    Desta forma, o nome acessível do link corresponde apenas à data do evento, por exemplo:

    • “20 maio”
    • “21 maio”
    • “23 maio”

    Contudo, o título do evento - informação principal para compreensão do destino do link - não integra o nome acessível do controlo.

    Esta implementação pode dificultar a navegação por utilizadores de leitores de ecrã, uma vez que, ao navegar por links, o contexto fornecido é insuficiente para compreender o conteúdo ou objetivo de cada ligação.

    Image

    Figura 1 - Link da agenda estruturado apenas sobre a data do evento, sem incluir programaticamente o título associado

    URL a verificar

    Recomendações

    • Garantir que o nome acessível do link inclui informação suficientemente descritiva sobre o destino da ligação;
    • Associar programaticamente o título do evento ao link, por exemplo através de aria-describedby;
    • Preferencialmente, incluir o próprio título do evento dentro do elemento <a>, permitindo que data e título façam parte do mesmo nome acessível;
    • Validar a navegação por links utilizando leitores de ecrã, assegurando que o destino de cada ligação é compreensível sem necessidade de contexto visual.

  • issue #73 Modais sem nome acessível programaticamente determinável

    etiqueta: chk 10 webetiqueta: NOKetiqueta: R 8.3

    Evidências

    Foi identificado um modal de visualização de imagem que não apresenta um nome programaticamente determinável, dificultando a sua identificação por utilizadores de tecnologias de apoio.

    O modal apresenta apenas um botão de fecho com aria-label="Close", mas o próprio conteúdo modal não possui um nome acessível associado (por exemplo através de aria-label, aria-labelledby ou título visível associado). Adicionalmente, a imagem apresentada no modal possui um atributo alt="", não fornecendo contexto ou descrição sobre o conteúdo exibido.

    Na prática, utilizadores de leitores de ecrã podem ter dificuldade em compreender:

    • que modal foi aberto;
    • qual o propósito do conteúdo apresentado;
    • ou o contexto da imagem visualizada.
    Image

    Figura 1 - Modal de visualização de imagem sem nome programaticamente acessível e imagem sem descrição associada

    URL a verificar

    Recomendações

    • Garantir que o modal possui um nome programaticamente determinável através de aria-label ou aria-labelledby;
    • Associar o modal a um título visível ou texto contextual que identifique o conteúdo apresentado;
    • Rever a utilização de alt="" em imagens informativas abertas em modal, garantindo descrição adequada quando relevante;
    • Validar a experiência com leitores de ecrã, assegurando que a abertura do modal comunica claramente o contexto ao utilizador;
    • Garantir conformidade com boas práticas de acessibilidade para diálogos/modais (role="dialog" ou dialog).

  • issue #54 Existência de elementos fora de landmarks semânticos

    etiqueta: chk 10 webetiqueta: NOKetiqueta: R 8.3

    Evidências:

    Verificou‑se que o conteúdo apresentado visualmente não está corretamente estruturado dentro das landmarks. Por exemplo, o rodapé está estruturado dentro da tag main. Embora exista uma tag footer a mesma está sendo preenchida pelo texto "© 2024 SGMDN" que é visível apenas para tecnologias de apoio.

    Image

    Figura 1 – Website estruturado com o rodapé fora do footer

    A inexistência de enquadramento destes elementos em regiões semânticas apropriadas (por exemplo, <header>, <main>, <nav>, <aside> ou <footer>) compromete a sua deteção e interpretação por tecnologias de apoio. Em consequência, leitores de ecrã e a navegação por teclado podem não percorrer nem anunciar estes elementos, impossibilitando o acesso por parte de utilizadores com deficiência visual ou motora.

    Esta situação cria uma barreira significativa à acessibilidade, uma vez que funcionalidades essenciais ficam inacessíveis a determinados perfis de utilizadores, contrariando os princípios de perceção, operabilidade e robustez.

    Recomendações:

    Garantir que todos os elementos interativos do website estejam corretamente integrados em landmarks semânticos apropriados, de acordo com a sua função e localização lógica na página.

    O conteúdo apresentado no rodapé deve estar contido dentro da tag footer.

  • issue #53 Landmarks com o mesmo papel sem nome acessível único

    etiqueta: chk 10 webetiqueta: NOKetiqueta: R 8.3

    Evidências

    Foram identificadas regiões da página expostas como landmarks com o mesmo papel sem um nome acessível único, dificultando a sua identificação por utilizadores de leitores de ecrã durante a navegação por regiões.

    Em particular, foram identificados elementos com role="region" e aria-label="carousel" repetidos na mesma página, originando múltiplas landmarks indistinguíveis entre si.

    Quando existem várias landmarks com o mesmo papel (ex.: múltiplas regiões, navegações ou áreas complementares), estas devem possuir nomes acessíveis distintos para permitir aos utilizadores compreender rapidamente o propósito de cada secção ao navegar por landmarks.

    Image

    Figura 1 - Landmarks do tipo região (role="region") com o mesmo nome acessível, dificultando a distinção entre secções da página

    URL a verificar

    Recomendações

    • Garantir que landmarks do mesmo tipo possuem nomes acessíveis únicos e descritivos;
    • Utilizar aria-label ou aria-labelledby para distinguir programaticamente cada região;
    • Evitar nomes genéricos repetidos como “carousel” quando existem múltiplos componentes semelhantes;
    • Utilizar designações que descrevam o conteúdo ou propósito da região (ex.: “Carrossel de notícias”, “Carrossel de destaques”, “Carrossel de campanhas”);
    • Validar a navegação por landmarks com leitores de ecrã para confirmar que cada região é anunciada de forma clara e distinta.

  • issue #27 Listagem de conteúdos sem estrutura semântica adequada

    etiqueta: chk 10 webetiqueta: NOKetiqueta: R 8.3

    Evidências

    Na página principal, têm várias secções em que cada item é apresentado como um conjunto de conteúdos relacionados (imagem, data, título, descrição e ligação para detalhe), estruturado com múltiplos elementos <div>.

    No entanto, estes itens não estão inseridos numa estrutura semântica de lista (<ul> / <li>), apesar de representarem claramente uma listagem de conteúdos homogéneos.

    Image

    Figura 1 – Listagem de notícias na página inicial estruturada com elementos <div> sem utilização de lista semântica

    Image

    Figura 2 – Listagem de notícias estruturada com elementos <div> sem utilização de lista semântica

    Como consequência, as tecnologias de apoio não conseguem identificar programaticamente que estes elementos pertencem a um conjunto, nem o número total de itens existentes.

    Quando os estilos CSS são desativados, os conteúdos passam a ser apresentados como blocos isolados, sem indicação clara da relação entre si, dificultando a compreensão da estrutura da informação.

    Notas Gerais

    • Conjuntos de conteúdos relacionados, como listagens de documentos, notícias ou resultados, devem ser estruturados com elementos HTML semânticos apropriados (ex.: listas <ul> / <ol> e <li>), de forma a permitir que tecnologias de apoio identifiquem corretamente o agrupamento e o número de itens.
    • A utilização exclusiva de elementos genéricos (<div>) para representar estes conjuntos pode comprometer a perceção da relação entre os conteúdos apresentados.

    URL a verificar

    Recomendações

    • Deve ser verificado este padrão em todo o website.
    • Os conjuntos de conteúdos que representem listagens (ex.: documentos, notícias, resultados) devem ser estruturados semanticamente como listas (<ul> ou <ol>), com cada item representado por um <li>.
    • Cada item da lista deve agrupar toda a informação relacionada (categoria, título, descrição e ações) dentro do respetivo <li>.
    • Evitar a utilização exclusiva de elementos genéricos (<div>) para representar agrupamentos de conteúdos.
    • Validar com leitores de ecrã para garantir que o agrupamento e o número de itens são corretamente anunciados.

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

etiqueta: NOK

Lista de evidências recolhidas:

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:

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:

Requisito 10.1 - Nos ficheiros PDF é possível, no mínimo, extrair o conteúdo textual para formato TXT

etiqueta: NOK

Lista de evidências recolhidas:

Checklist Conteúdo

etiqueta: NOK

Nível de conformidade:

  • Checklist Conteúdo: 35.3% (6/17)
    • Requisitos avaliados: 17 (17 aplicáveis)
    • Requisitos OK: 6
    • Requisitos NOK: 11

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 #20 Falta de resumo na página inicial do website

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

    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

    Evidências:

    A página inicial do website do Portal da Defesa Nacional apresenta uma frase visível no topo esquerdo da página, sem necessidade de scroll. No entanto, esse resumo não descreve de forma adequada o propósito do website, uma vez que este não se limita a divulgações, abrangendo também notícias, legislação, missões, estratégias, entre outros conteúdos. Esta limitação pode dificultar a compreensão imediata da finalidade do site por parte do utilizador.

    Image

    Imagem da página inicial do Portal da Defesa Nacional sem fazer scroll

    Recomendações:

    O resumo apresentado na página inicial deve ser revisto de forma a descrever claramente o propósito do website, incluindo os principais tipos de conteúdos e serviços disponibilizados. Esta descrição deve ser concisa, informativa e orientada para ajudar o utilizador a compreender rapidamente a utilidade e abrangência do site.

    Como exemplo, pode ser consultado o website acessibilidade.gov.pt, que apresenta um resumo simples e claro logo na página inicial, permitindo compreender rapidamente o seu propósito.

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

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

Lista de evidências recolhidas:

  • issue #21 Glossário com difícil acesso

    etiqueta: R 1.2etiqueta: melhoriaetiqueta: chk conteúdo

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

    Evidências:

    Embora os termos complexos estejam reunidos num glossário, o acesso a este recurso não é facilmente identificável. Atualmente, o glossário encontra-se na secção “Comunicação” do menu, o que pode dificultar a sua descoberta por parte dos utilizadores durante a navegação.

    Image

    Recomendações:

    Deve ser garantido um acesso mais direto e visível ao glossário, por exemplo através de uma ligação no rodapé, no menu principal ou em destaque nas páginas relevantes. Adicionalmente, sempre que possível, os termos complexos no conteúdo devem incluir ligações diretas para as respetivas definições, facilitando a sua consulta no contexto de utilização.

Requisito 1.4 - A informação sobre a entidade responsável pelo conteúdo está em todas as páginas

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #8 Informação da Entidade Responsável Não Escrita por Extenso

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

    A informação sobre a entidade responsável pelo conteúdo está em todas as páginas.
    – ver requisito 1.4 na lista Conteúdo

    Evidências:

    Todas as páginas devem apresentar o nome da entidade responsável pelos conteúdos publicados no site. O nome da entidade pode ser apresentado através de um logótipo ou texto, mas deve estar por extenso.

    Apesar de existir no rodapé o logótipo da entidade e um acesso rápido aos contactos, verifica-se que o nome da entidade responsável não se encontra indicado de forma completa, sendo apenas apresentada a menção “2026 SGMDN”, o que pode não ser suficientemente claro para todos os utilizadores.

    Os direitos da entidade responsável pelo conteúdo está presente em todas as páginas no rodapé do website do Portal da Defesa Nacional.

    Image

    Imagem do rodapé do Portal da Defesa Nacional com os direitos não escritos por extenso.

    Recomendações:

    Deve ser adicionado o nome da entidade por extenso em todo o website, como é possível observar no acessibilidade.gov.pt:

    Image

    Imagem de exemplo do rodapé do acessibilidade.gov.pt

Requisito 2.1 - O tipo de letra do corpo do documento é adequado e o tamanho da letra é, no mínimo, de 12 pontos

etiqueta: NOK

Lista de evidências recolhidas:

Requisito 2.3 - Blocos e linhas de texto com largura não superior a 100 caracteres

etiqueta: NOK

Lista de evidências recolhidas:

Requisito 2.4 - O espaçamento entre linhas não é inferior a 1.5x o tamanho da letra

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #17 O espaçamento entre linhas está abaixo do recomendado

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

    O espaçamento entre linhas não é inferior a 1.5x o tamanho da letra.
    – ver requisito 2.4 na lista Conteúdo

    Evidências

    • Para assegurar uma boa leitura, o espaçamento entre linhas não deve ser inferior a 1.5x em relação ao tamanho do texto a ser analisado.

    Na evidência 01, há blocos de textos nas página Inicial, por exemplo na secção “Ligações”, possui uma tabela em que o espaçamento entre linhas do conteúdo é de 22.8px para um tamanho de letra de 16px. (Figura 1)



    Image

    Figura 1 - Textos com espaçamento inferior ao recomendado.

    A evidência 02 revela a página Contactos onde há blocos de textos com espaçamento apenas 20px para um tamanho de letra de 14px. (Figura 2)

    Image

    Figura 2 - O bloco de conteúdo sobre as “Relações Públicas do Ministério da Defesa Nacional” possui espaçamento inferior ao recomendado

    URLs a verificar

    Recomendação

    Para a evidência 01, o espaçamento deveria ser, no mínimo 24px. Já para evidência 02 o espaçamento deveria ser, no mínimo 21px.
É necessário rever todo website, incluindo informações de formulários para garantir o espaçamento mínimo recomendado, relativo ao tamanho da letra.

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #12 Excesso de opções no subnível do menu de navegação

    etiqueta: NOKetiqueta: chk conteúdoetiqueta: R 3.1

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

    Evidências:

    O menu principal do website do Portal da Defesa Nacional contém secções como “Política de Defesa”, “A Defesa e Eu” e “Comunicação”, ultrapassando o limite recomendado de 9 opções. Um número excessivo de itens no menu pode dificultar a navegação e a tomada de decisão por parte do utilizador.

    Image

    Imagem do maior nível de navegação com 17 opções.

    Recomendações:

    Deve ser revista a estrutura do menu principal, reduzindo o número de opções apresentadas ao utilizador. Sempre que possível, os conteúdos devem ser reorganizados e agrupados de forma lógica em categorias mais abrangentes, promovendo uma navegação mais simples, clara e intuitiva.

    Com vista à melhoria da usabilidade e conformidade com os princípios de acessibilidade, recomenda-se:

    • Reduzir o número de opções no subnível, agrupando conteúdos relacionados sob categorias mais abrangentes.

    • Reorganizar a arquitetura de informação para garantir uma hierarquia mais simples e intuitiva.

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

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

Lista de evidências recolhidas:

  • issue #22 O menu secundário desaparece em certos breakpoints

    etiqueta: R 3.2etiqueta: melhoriaetiqueta: chk conteúdo

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

    Evidências:

    O menu principal do website do Portal da Defesa Nacional está sempre presente no topo da página por todo o domínio.

    Image

    Figura 01: Imagem da página principal com o menu principal presente no topo da página

    Foi identificado que algumas páginas incluem um menu secundário, nomeadamente:

    Verificou-se ainda que, na versão mobile, o menu secundário surge com o mesmo aspeto do menu principal e posicionado a meio da página (Ver figura 02), o que pode gerar confusão na navegação.

    Image

    Figura 02: Imagem do menu secundário na versão mobile.

    Recomendações:

    Recomenda-se que o menu secundário funcione como um prolongamento coerente do menu principal, garantindo consistência na sua apresentação e comportamento. Nesse sentido, deverá estar presente de forma uniforme em todos os subníveis de navegação ou, em alternativa, ser removido por completo, uma vez que atualmente não surge de forma consistente em todas as páginas do website. Esta correção permitirá evitar discrepâncias na experiência e na perceção do utilizador relativamente à sua navegação.

    Adicionalmente, é recomendável rever e corrigir a versão mobile, assegurando uma hierarquia visual clara entre menus, um posicionamento adequado dos elementos e uma distinção inequívoca entre navegação principal e secundária, de forma a melhorar a usabilidade e a experiência do utilizador em dispositivos móveis.

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:

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

etiqueta: NOK

Lista de evidências recolhidas:

Requisito 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:

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:

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

etiqueta: NOK

Lista de evidências recolhidas:

Checklist Transação

etiqueta: NOK

Nível de conformidade:

  • Checklist Transação: 36.4% (4/11)
    • Requisitos avaliados: 13 (2 N/A excluídos, 11 aplicáveis)
    • Requisitos OK: 4
    • Requisitos NOK: 7
    • Requisitos N/A: 2

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

etiqueta: NOK

Lista de evidências recolhidas:

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #83 Formulários PDF inacessíveis para tecnologias de apoio

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

    Evidências

    Validado o ficheiro PDF Formulário de Pedido de Pedido de Visita​ presente na página Forte de são Julião da Barra, através do browser e do Adobe Acrobat Reader, e foi verificado que é um formulário longo cujo conteúdo está distribuído por 2 e 3 páginas, respetivamente.

    No entanto, como este formulário PDF não está acessível, os utilizadores que dependem de leitores de ecrã não conseguem aceder devidamente ao seu conteúdo.

    Nos casos dos formulários PDF, uma solução mais acessível seria disponibilizar os formulários diretamente no site, em vez de em formato PDF.

    Image

    Figura - Análise do formulário na página Forte de são Julião da Barra através de navegação por teclado (Tab e Shift+Tab) e do leitor de ecrã.

    URLs a verificar
    https://www.defesa.gov.pt/pt/adefesaeeu/fsjb/Paginas/default.aspx

    Recomendações

    • Para os fomulário PDF, recomensa-se disponibilizar os formulários diretamente no site, em vez de em formato PDF.

  • issue #71 Existem formulários longos sem divisão por passos

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

    Evidências

    Verifica-se que existem formulários no website muito longos, nos quais é solicitada ao utilizador toda a informação de uma só vez.

    Image

    Figura - Análise do formulário da página Insígnia do Antigo Combatente através de navegação por teclado (Tab e Shift+Tab) e do leitor de ecrã.

    URL:

    https://www.defesa.gov.pt/pt/adefesaeeu/ac/direitos/iac/Paginas/default.aspx

    Recomendações

    • Recomendamos rever a estrutura dos formulários mais longos, de forma a segmentar os passos em várias páginas ou secções.

Requisito 1.3 - Os formulários com mais de uma página têm a sequência de passos ilustrada

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

Lista de evidências recolhidas:

  • issue #72 R 1.3 - Transação -(Melhoria) Formulários PDF inacessíveis para leitores de ecrã

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

    Evidências

    Validado o ficheiro PDF Formulário de Pedido de Pedido de Visita​ presente na página Forte de são Julião da Barra, através do browser e do Adobe Acrobat Reader, o formulário possui uma sequência de passos ilustrada (“1. Entidade Requerente”, “2. Visitantes”, etc.).

    No entanto, como este formulário PDF não está acessível, os utilizadores que dependem de leitores de ecrã não conseguem aceder devidamente ao seu conteúdo.

    Image

    Figura - Análise do formulário na página Forte de são Julião da Barra através de navegação por teclado (Tab e Shift+Tab) e do leitor de ecrã.

    URLs a verificar
    https://www.defesa.gov.pt/pt/adefesaeeu/fsjb/Paginas/default.aspx

    Recomendações

    • Recomenda-se que para formulários PDF, uma solução mais acessível seria disponibilizar os formulários diretamente no site, em vez de em formato PDF.

Requisito 2.1 - O tamanho dos campos deve refletir o tamanho previsível dos dados

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #81 Campos do formulário PDF apresentam dimensões adequadas ao tipo de dados esperado

    etiqueta: chk transaçãoetiqueta: R 2.1etiqueta: melhoria

    O tamanho dos campos deve refletir o tamanho previsível dos dados.
    – ver requisito 2.1 na lista Transação

    Evidências:

    Verificou-se que os campos do formulário PDF da página Pedido de visita apresentam dimensões adequadas ao tipo de informação esperado, permitindo uma relação coerente entre o tamanho dos campos e os dados a introduzir.

    Os diferentes campos apresentam larguras ajustadas ao conteúdo previsível, facilitando o preenchimento e compreensão do formulário.

    Contudo, apesar das dimensões adequadas dos campos, o formulário PDF apresenta limitações de acessibilidade na utilização com tecnologias de apoio, dificultando a navegação, identificação e preenchimento correto dos elementos do formulário por utilizadores de leitores de ecrã.

    Formulário PDF com dimensões adequadas dos campos, mas com limitações de acessibilidade na utilização com tecnologias de apoio

    Figura 01 — Formulário PDF com dimensões adequadas dos campos, mas com limitações de acessibilidade na utilização com tecnologias de apoio.

    Recomendação
    Recomenda-se que, sempre que possível, os formulários sejam disponibilizados diretamente em páginas web, garantindo melhor compatibilidade com tecnologias de apoio e uma experiência de preenchimento mais acessível para todos os utilizadores.

  • issue #50 Campos de formulário apresentam dimensões desadequadas ao tipo de dados esperado

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

    O tamanho dos campos deve refletir o tamanho previsível dos dados.
    – ver requisito 2.1 na lista Transação

    Evidências:

    Na página Contactos para a Imprensa, o campo de seleção “Para” apresenta uma largura desadequada relativamente ao conteúdo previsível apresentado no interior do componente.

    O texto da opção disponível surge visualmente comprimido dentro do campo de seleção, dificultando a leitura e perceção integral da informação apresentada.

    Campo de seleção com largura desadequada ao conteúdo

    Figura 01 — Campo de seleção “Para” com largura desadequada ao conteúdo.

    Na página Insígnia do Antigo Combatente, alguns campos apresentam largura excessiva relativamente ao tamanho previsível dos dados a introduzir.

    Esta situação verifica-se, por exemplo, nos campos:

    • Nº do Cartão de Cidadão ou do BI Civil
    • Nº de Identificação do BI Militar
    • Nº da Porta
    • Código Postal
    Campos com largura excessiva relativamente ao conteúdo esperado

    Figura 02 — Campos com largura excessiva relativamente ao conteúdo esperado.

    Na página Formulario UPA o campo de seleção “Telefone” apresenta largura excessiva relativamente ao tamanho previsível dos dados a introduzir.

    Campo “Telefone” com largura excessiva relativamente ao conteúdo esperado

    Figura 03 — Campo “Telefone” com largura excessiva relativamente ao conteúdo esperado.

    Recomendações:
    Recomendamos que os campos dos formulários sejam ajustados de acordo com o tamanho previsível dos dados esperados, garantindo maior coerência visual e melhor perceção da informação a introduzir.

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #82 Legendas dos campos do formulário PDF apresentam-se de forma breve e clara

    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

    Evidências:

    Verificamos que o formulário PDF da página Pedido de visita apresenta limitações de acessibilidade na utilização com leitores de ecrã.

    Durante os testes realizados com tecnologia de apoio (NVDA) , não foi possível navegar e preencher corretamente os campos do formulário, não sendo igualmente anunciados de forma adequada os respetivos rótulos e elementos de formulário.

    Esta situação dificulta a utilização autónoma do formulário por utilizadores de leitores de ecrã. (Figura 01)

    Formulário PDF com limitações de acessibilidade na utilização com leitores de ecrã

    Figura 01 — Formulário PDF com limitações de acessibilidade na utilização com leitores de ecrã.

    Adicionalmente, ainda no formulário PDF da página Pedido de visita verificamos que alguns campos do formulário PDF apresentam legendas pouco claras relativamente à informação que deve ser introduzida.

    Esta situação verifica-se, por exemplo, nos campos:

    • Ponto de Contato/Responsável pelo pedido
    • Descrição do grupo

    As designações utilizadas podem gerar dúvidas quanto ao tipo de informação esperada no preenchimento dos campos.
    (Figura 02)

    Campos do formulário PDF com legendas pouco claras relativamente à informação solicitada

    Figura 02 — Campos do formulário PDF com legendas pouco claras relativamente à informação solicitada.

    URL a verificar:

    Recomendações:
    Recomenda-se a revisão das legendas dos campos do formulário, utilizando designações mais claras e objetivas relativamente à informação que deve ser introduzida.

    Adicionalmente, recomenda-se que os formulários sejam disponibilizados diretamente em páginas web, em vez de exclusivamente em formato PDF, garantindo melhor compatibilidade com leitores de ecrã e restantes tecnologias de apoio.

  • issue #48 O texto do placeholder está a substituir o rótulo

    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

    Evidências:

    No campo de pesquisa do website, o título associado ao campo não se encontra visível na interface gráfica, estando apenas disponível através de uma label oculta no código display:none.

    O campo apresenta apenas o placeholder “Pesquisar”, que não substitui adequadamente uma legenda visível e permanentemente associada ao campo.

    Esta situação pode dificultar a identificação clara da finalidade do campo, especialmente em contextos de usabilidade e acessibilidade.

    Análise do campo de pesquisa geral através do Google Inspector

    Figura 01 — Análise do campo de pesquisa geral através do Google Inspector, com etiqueta oculta e utilização exclusiva de texto placeholder.

    Na página Formulário UPA, alguns campos utilizam apenas texto placeholder no interior dos inputs como forma de identificação do campo, sem apresentação de etiqueta visível associada.

    Esta situação verifica-se, por exemplo, nos campos:

    • Nome
    • Telefone
    • Morada

    O placeholder acaba por substituir visualmente o rótulo do campo, deixando de estar visível após o início da introdução de dados.

    Campos do formulário identificados apenas através de texto placeholder

    Figura 02 — Campos do formulário identificados apenas através de texto placeholder, sem etiqueta visível associada.

    Recomendações:
    Recomendamos que os campos de formulário e pesquisa sejam revistos para garantir que as respetivas legendas/rótulos permanecem sempre visíveis na interface gráfica.

    Adicionalmente, os placeholders não devem ser utilizados como substitutos de rótulos visíveis, devendo existir uma associação clara e permanente entre o campo e a sua legenda.

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #77 Não é possível identificar campos obrigatórios nos formulários em PDF

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

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

    Evidências:

    Verificámos que, no formulário Pedido de Visita, os campos de preenchimento obrigatório não se encontram identificados de forma clara.

    A obrigatoriedade dos campos não é comunicada visualmente de forma evidente nem transmitida corretamente às tecnologias de apoio, como leitores de ecrã.

    Sempre que possível, recomenda-se a disponibilização destes formulários diretamente em páginas web, em vez de exclusivamente em formato PDF. Em formulários web, os campos obrigatórios devem ser corretamente identificados através de atributos como required ou aria-required="true", garantindo a sua perceção por tecnologias de apoio.

    Adicionalmente, deve também ser apresentada uma indicação visual clara junto ao rótulo — por exemplo, “(Campo obrigatório)” — para que todos os utilizadores consigam identificar facilmente os campos que têm obrigatoriamente de preencher.

    Formulário Pedido de Visita sem identificação clara dos campos obrigatórios

    Figura 01 — Formulário “Pedido de Visita” sem identificação clara dos campos de preenchimento obrigatório, quer visualmente quer através de tecnologias de apoio.

    Recomendações:
    Recomenda-se que os campos obrigatórios dos formulários PDF sejam identificados de forma clara e consistente, tanto visualmente como para tecnologias de apoio, permitindo a sua correta perceção por todos os utilizadores.

    Uma sugestão é ser disponibilizar os formulários diretamente em páginas web, garantindo melhor compatibilidade com leitores de ecrã e restantes requisitos de acessibilidade.

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

etiqueta: N/A

Lista de evidências recolhidas:

  • issue #1 Inexistência de ações longas

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

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

    Na análise realizada, não foram identificadas ações longas que exijam comunicação de estado ao utilizador.

    Desta forma, considera-se que o critério é não aplicável.

Requisito 4.2 - As ações destrutivas nunca devem ser permanentes; deve ser sempre possível desfazer a operação

etiqueta: N/A

Lista de evidências recolhidas:

  • issue #78 Não existem formulários que permitam ações destrutivas pelo utilizador

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

    Evidências

    Não identificamos formulários que permitem o utilizador fazer ações destrutivas e por esse motivo, consideramos esse critério como "Não aplicável".

    Recomendações

    No response

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

etiqueta: NOK

Lista de evidências recolhidas:

  • issue #79 Formulário em PDF não apresenta mensagens de erro junto aos campos de preenchimento

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

    Evidências

    Verificou-se que no Formulário de Pedido de Pedido de Visita, presente na página Portal da Defesa Nacional em formato PDF, não apresenta mecanismos claros de validação nem mensagens de erro associadas aos campos de preenchimento.

    Na prática, quando um campo é preenchido incorretamente ou omitido, não existem mensagens de erro junto aos respetivos campos que permitam ao utilizador identificar claramente o problema e a sua origem.

    Esta limitação dificulta particularmente a utilização por pessoas com deficiência visual, cognitiva ou utilizadores de tecnologias de apoio, uma vez que não existe feedback contextual próximo do campo que necessita de correção.

    Image

    Figura 1 - Formulário PDF sem mensagens de erro apresentadas junto aos campos de preenchimento

    Recomendações

    • Garantir que os erros de preenchimento são apresentados de forma clara junto aos respetivos campos;
    • Assegurar que as mensagens de erro permanecem próximas dos campos a que dizem respeito, facilitando a sua identificação;
    • Sempre que possível, substituir formulários PDF por formulários web acessíveis, permitindo validação contextual e feedback imediato ao utilizador.

  • issue #64 Mensagens de erro não estão corretamente associadas a todos os campos

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

    Evidências

    No formulário de contacto, os campos obrigatórios (Nome, Email, Assunto e Mensagem) apresentam mensagens de erro no DOM, sendo que em alguns casos estas mensagens estão parcialmente associadas ao campo através de atributos como aria-errormessage e aria-invalid.

    Contudo, verifica-se um problema de consistência na associação programática das mensagens de erro:

    O campo “Mensagem” (tbContactosMessage) apresenta aria-invalid="true", mas não possui associação explícita à mensagem de erro através de aria-errormessage ou aria-describedby.
    Embora exista um elemento com a mensagem de erro (rfvContactosMessage), este não está corretamente referenciado pelo campo.
    Em alguns campos, a associação entre input e mensagem de erro não é consistente ou completa, o que pode impedir leitores de ecrã de anunciar corretamente o erro associado ao respetivo campo.
    As mensagens de erro são apresentadas visualmente, mas a sua relação programática com os campos não é garantida em todos os casos.

    Image

    Figura 1 - Campo “Mensagem” sem associação programática à respetiva mensagem de erro

    URL a verificar

    Recomendações

    • Garantir que todas as mensagens de erro possuem um identificador único no DOM;
    • Associar programaticamente cada mensagem de erro ao respetivo campo através de aria-describedby ou aria-errormessage;
    • Garantir consistência na utilização de aria-invalid="true" em todos os campos inválidos;
    • Assegurar que todos os campos obrigatórios têm mensagens de erro corretamente ligadas e anunciadas por leitores de ecrã;
    • Validar o comportamento com tecnologias de apoio e navegação por teclado.

  • issue #61 Mensagem de erro global não identifica nem direciona os erros do formulário

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

    Evidências

    No formulário de contacto, após submissão inválida, são apresentadas mensagens de erro na vizinhança dos campos obrigatórios (Nome, Email, Assunto e Mensagem).

    Contudo, verifica-se que as mensagens de erro encontram-se distribuídas por diferentes elementos e containers, não existindo uma estrutura consistente que permita associar programaticamente cada campo à totalidade da respetiva mensagem de erro.

    Por exemplo:

    • o campo Email apresenta a mensagem “Formato de email inválido, o formato deve ser o seguinte, nome@dominio.pt”, mas a construção da mensagem encontra-se separada do restante mecanismo de validação;
    • o campo Mensagem apresenta erro visualmente, mas a associação programática entre o campo inválido e a respetiva mensagem não é consistente;
    • as mensagens de erro são apresentadas junto aos campos, mas a sua estrutura dificulta a correta interpretação e anúncio por tecnologias de apoio.

    Esta abordagem pode dificultar que utilizadores de leitores de ecrã compreendam integralmente o erro associado a cada campo, bem como os passos necessários para a sua correção.

    Image

    Figura 1 - Mensagens de erro apresentadas na vizinhança dos campos, mas distribuídas por diferentes elementos e sem associação programática consistente

    URL a verificar

    Recomendações

    • Garantir que cada campo inválido possui uma associação programática consistente à respetiva mensagem de erro;
    • Estruturar as mensagens de erro de forma uniforme, evitando a sua fragmentação por múltiplos elementos sem relação explícita;
    • Utilizar aria-describedby ou aria-errormessage de forma consistente para associar cada campo à sua mensagem de erro;
    • Garantir que aria-invalid="true" é aplicado corretamente aos campos inválidos;
    • Validar o comportamento com leitores de ecrã e navegação exclusivamente por teclado.

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 #80 R 4.4 - Transação -Formulário em PDF não apresenta instruções para resolução dos erros de preenchimento

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

    Evidências

    Verificou-se que no Formulário de Pedido de Pedido de Visita, presente na página Portal da Defesa Nacional em formato PDF, não fornece mensagens de erro nem instruções concretas que auxiliem o utilizador na correção de erros de preenchimento.

    Quando um campo é preenchido incorretamente, ou quando informação obrigatória é omitida, não existem orientações claras que expliquem os passos necessários para resolver o problema.

    A ausência de feedback orientador pode levar os utilizadores a processos de tentativa e erro, dificultando a conclusão eficaz da tarefa.

    Image

    Figura 1 - Formulário PDF sem mensagens de erro ou instruções de correção dos campos preenchidos incorretamente

    Recomendações

    • Garantir que os erros de preenchimento incluem orientações claras e sucintas sobre como resolver o problema;
    • Evitar mensagens genéricas ou ausência de feedback em situações de erro;
    • Fornecer exemplos ou instruções concretas sempre que exista um formato esperado de preenchimento;
    • Sempre que possível, substituir formulários PDF por formulários web acessíveis, permitindo validação contextual e feedback imediato ao utilizador.

  • issue #65 Instruções para correção do campo Email não são apresentadas de forma consistente ao utilizador

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

    Evidências

    No formulário Contactos para a Imprensa, o campo Email apresenta uma mensagem de validação visível no DOM:

    “Formato de email inválido, o formato deve ser o seguinte, nome@dominio.pt”

    Contudo, verifica-se que esta mensagem:

    • encontra-se dividida por múltiplos elementos (rfvContactosEmail, regexEmailValid);
    • inclui elementos com visibility: hidden, não sendo expostos a tecnologias de apoio;
    • não é apresentada de forma consistente como uma única mensagem associada ao campo;
    • pode não ser anunciada corretamente por leitores de ecrã no momento da validação.

    Apesar de a mensagem estar visualmente presente após erro, a sua estrutura fragmentada e dependente de diferentes containers compromete a sua perceção consistente em contexto de tecnologias de apoio.

    Image

    Figura 1 - Campo Email com mensagem de erro visualmente apresentada, mas não anunciada ao leitor de ecrã

    URL a verificar

    Recomendações

    • Consolidar a mensagem de validação num único elemento associado ao campo;
    • Evitar a utilização de visibility: hidden para mensagens que devem ser anunciadas por leitores de ecrã;
    • Garantir que a mensagem de erro é exposta de forma consistente no DOM quando ocorre validação;
    • Associar corretamente a mensagem ao campo através de aria-describedby ou aria-errormessage;
    • Garantir que a mensagem é percecionável por tecnologias de apoio no momento da validação.

Outras violações

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

Lista de evidências recolhidas:

  • issue #62 Outras violações - Pedido de Login de admin ao navegar no website

    etiqueta: outras violaçõesetiqueta: melhoria

    Durante a navegação em determinadas páginas do website, é apresentado um alerta que aparenta corresponder a um pedido de autenticação administrativa do “SharePoint”. Quando o utilizador cancela esse pedido, surge posteriormente uma barra/tab adicional sob o header do “SharePoint”, identificada com o nome de uma conta (“Patrícia Joana M. F. Pereira”).

    Após a ocorrência deste comportamento, a interface permanece alterada apenas nessa página específica até que o utilizador limpe o cache do navegador. Em pelo menos um dos casos observados, o utilizador ficou impossibilitado de aceder corretamente à página (ver figura 01), sem indicação clara de como resolver a situação.

    Esta ocorrência representa um potencial risco de segurança e de exposição indevida de componentes administrativos ou internos do sistema. A apresentação de elementos associados a autenticação administrativa pode incentivar tentativas indevidas de acesso por parte de utilizadores mal-intencionados ou gerar desconfiança relativamente à segurança da plataforma.

    Além disso, o comportamento observado cria uma experiência inconsistente e confusa para utilizadores comuns, que poderão não compreender a origem do problema nem saber como recuperar o funcionamento normal do website.

    Image

    Figura 01: Incapacidade de acessar o website devido ao pedido de autenticação.

    Image

    Figura 02: Pedido de autenticação ao navegar no website. Acontecimento na página: https://www.defesa.gov.pt/pt/adefesaeeu/asc/Paginas/default.aspx

    Image

    Figura 03: Após cancelar o pedido de autenticação a tab do "SharePoint" aparece debaixo do header permanentemente. Acontecimento na página: https://www.defesa.gov.pt/pt/pdefesa/ac/CMS

    Recomendações:

    Recomenda-se a análise técnica urgente da integração entre os sistemas envolvidos (SharePoint e mecanismos de autenticação), de forma a identificar a origem da exposição indevida de componentes administrativos e prevenir que conteúdos ou sessões internas sejam apresentados a utilizadores públicos.

  • issue #60 Outras violações - Foco não está visível na navegação por teclado e leitor de ecrã

    etiqueta: outras violaçõesetiqueta: melhoria

    Ao navegar pelo website utilizando o teclado ou leitor de ecrã, nem sempre o indicador de foco se encontra visível, dificultando significativamente a navegação, em particular para utilizadores que dependem exclusivamente deste meio de interação.

    Durante a navegação sequencial através da tecla TAB, em alguns momentos o foco não é apresentado de forma perceptível, sendo apenas possível inferir a sua existência através da barra de estado do navegador, o que não constitui uma solução acessível nem adequada. Como por exemplo nos links da página de destaques (Ver figura 01).

    Image

    Figura 01: Utilizando o teclado o foco está no link: "XII Fórum de Saúde Militar da CPLP" mas não existe highlight.É possível ver pelo indicador no canto inferior esquerdo da página que o foco está no link Disponível em: https://www.defesa.gov.pt/pt/pdefesa/cplp/destaques/Paginas/default.aspx#linkScroll

    URL's a verificar:

    Recomendações:

    Garantir que todos os elementos interativos do website apresentam um indicador de foco visível, suficientemente contrastante e consistente, sempre que recebem foco através da navegação por teclado.

    O estilo de foco deverá:

    • Ser claramente percetível visualmente (ex.: contorno, sublinhado ou mudança de cor);
    • Manter contraste adequado em relação ao fundo;
    • Não ser removido através de regras CSS como outline: none sem alternativa equivalente;
    • Acompanhar corretamente a ordem lógica da navegação por teclado.

    Esta melhoria é essencial para assegurar uma navegação acessível a utilizadores com deficiência visual, motora ou cognitiva

  • issue #58 Outras violações - Website em baixa repetidamente

    etiqueta: outras violaçõesetiqueta: melhoria

    Evidências:

    Durante a utilização do website, ocorre frequentemente a apresentação de mensagens de erro “502 Bad Gateway”. Para além da recorrência do erro indicar possíveis problemas de estabilidade ou comunicação com o servidor, a mensagem é apresentada exclusivamente em inglês.

    Considerando que o website pertence à Defesa Nacional Portuguesa e que uma grande parte dos seus utilizadores terá o português como língua principal, esta situação pode dificultar a compreensão do problema e gerar confusão ou insegurança relativamente ao estado da plataforma.

    A apresentação de mensagens técnicas não traduzidas compromete a clareza da comunicação com o utilizador e prejudica a experiência de utilização, sobretudo para utilizadores com menor literacia digital ou menor conhecimento de línguas estrangeiras.

    Image

    Imagem de erro do lado do servidor 502.

    Recomendações:

    Recomenda-se a análise e correção das causas técnicas que originam os erros “502 Bad Gateway”, de forma a reduzir a frequência destas ocorrências e melhorar a estabilidade geral da plataforma.

    Adicionalmente, as mensagens de erro apresentadas ao utilizador devem:

    • ser disponibilizadas em português;
    • respeitar o idioma atualmente selecionado no website, caso exista suporte multilingue.

  • issue #56 Outras violações - O botão “Limpar” remove os dados do formulário sem confirmação ou possibilidade de recuperação

    etiqueta: outras violaçõesetiqueta: melhoria

    ** Evidências **

    No formulário de contacto, o botão “Limpar” remove imediatamente todos os dados introduzidos pelo utilizador, sem apresentar qualquer pedido de confirmação nem permitir desfazer a ação.

    Esta operação pode levar à perda acidental de informação já preenchida, obrigando o utilizador a repetir o preenchimento integral do formulário.

    O problema pode impactar particularmente utilizadores com limitações cognitivas, motoras ou utilizadores de tecnologias de apoio, aumentando o risco de perda involuntária de conteúdo durante a interação.

    Image

    Figura 1 - Botão “Limpar” elimina os dados do formulário sem confirmação prévia ou possibilidade de recuperação

    URL a verificar

    ** Recomendações **

    • Evitar a remoção imediata dos dados introduzidos sem mecanismo de salvaguarda;
    • Solicitar confirmação antes de executar a limpeza do formulário (ex.: modal ou diálogo de confirmação);
    • Em alternativa, disponibilizar mecanismo de desfazer a ação após a limpeza;
    • Validar o comportamento com navegação por teclado e tecnologias de apoio.

  • issue #55 Outras violações - Duplicação da componente de paginação

    etiqueta: outras violaçõesetiqueta: melhoria

    Evidências:

    Na secção de notícias, quando é aplicado um filtro que devolve resultados suficientes apenas para uma única página, continuam a ser apresentadas duas componentes de paginação na interface (uma no topo e outra no fundo da lista de resultados), apesar de não existir navegação entre páginas.

    Esta situação cria ruído visual e pode induzir os utilizadores em erro, levando-os a acreditar que existem páginas adicionais de conteúdo disponíveis. Além disso, a presença de controlos de paginação sem utilidade funcional reduz a clareza da interface e afeta a consistência da experiência de utilização.

    Do ponto de vista programático, a duplicação destas componentes resulta também na existência de duas landmarks com a mesma designação (“Paginação das Notícias”), o que pode comprometer a navegação assistida e gerar ambiguidades para utilizadores de tecnologias de apoio.

    Image

    Imagem da página de notícias com o filtro de "IDN" ativado.

    URL's a verificar:

    Recomendações:

    Implementar uma validação lógica que verifique o número total de páginas disponíveis após a aplicação dos filtros.

    Caso exista apenas uma página de resultados:

    • ocultar completamente os componentes de paginação; ou
    • apresentar a paginação em estado desativado, desde que fique claro que não existem páginas adicionais.

Significado das etiquetas utilizadas