Relatório de avaliação manual

Sim 1.1

• O menu principal está num elemento <nav aria-label="Navegação principal"> com uma lista <ul>/<li>; cada submenu é também uma lista <ul> (ex.: Quem Somos, Vitórias, Quero Apoiar, Contactos).
• No telemóvel, o menu abre num diálogo (role="dialog", aria-modal) com a mesma estrutura de lista.
• Sem CSS, o menu aparece como lista hierarquizada (ver captura).

Sim 1.2

• Cada opção com submenu tem um botão próprio (aria-expanded, aria-controls) que abre o submenu com Enter/Espaço; Esc fecha e devolve o foco ao botão.
• Com o rato, o submenu abre ao passar o cursor e também com clique no botão.
• Foco visível em todos os itens (anel de foco focus-visible). A ordem de tabulação segue a ordem visual.

Sim 1.3

• A única imagem-link do menu é o logótipo, que tem aria-label="Página inicial — Capacitando famílias, mudando comunidades" e alt na imagem.
• O botão de opções de acessibilidade (ícone) tem aria-label="Opções de acessibilidade" e a imagem é decorativa (alt="").

Sim 2.1

• Todas as páginas da amostra têm exatamente um <h1> (verificado automaticamente com script e pelo AccessMonitor — prática "Identifiquei exatamente um cabeçalho de nível 1").
• Na página inicial, o h1 é "Pais em Rede — Associação Nacional de famílias de pessoas com deficiência"; os títulos dos slides do carrossel são h2.

Sim 2.2

• Hierarquia h1 → h2 → h3 sem saltos em todas as páginas da amostra (verificado com script que percorre os cabeçalhos visíveis).
• Os textos vindos do backoffice (notícias, vitórias, projetos) têm os níveis de cabeçalho ajustados automaticamente ao contexto da página (função ajustarCabecalhos).

Sim 3.1

• A única tabela de dados da amostra está na Declaração de Acessibilidade ("Resumo da contribuição do back-end"): cabeçalhos de coluna em <th scope="col"> e de linha em <th scope="row">.
• Não são usadas tabelas para paginação (ver 8.5).

Sim 3.2

• A tabela tem <caption> ("Tabela resumo de como o back-end contribui para cada aspecto da conformidade WCAG 2.1 AA.").

Sim 4.1

• Todos os campos têm <label for> associado ao id do campo; clicar na etiqueta coloca o cursor no campo.
• Os ids são únicos por formulário (prefixo do formulário), mesmo quando a página tem dois formulários com campos de nome igual (/apoio).
• Grupos de opções (radio) usam <fieldset> e <legend>.

Sim 4.2

• Campos obrigatórios com required e aria-required="true" — o leitor de ecrã anuncia "obrigatório".
• Visualmente: asterisco e, no início de cada formulário, a nota "Os campos assinalados com * são de preenchimento obrigatório".

Sim 4.3

• As mensagens de erro aparecem por baixo do campo, com role="alert" (são lidas de imediato), e estão ligadas ao campo por aria-describedby; o campo fica com aria-invalid="true".
• Ex.: "Preencha «Nome» antes de continuar.", "Introduza um email válido, no formato nome@exemplo.pt".

Sim 5.1

• Todas as imagens têm atributo alt: informativas com texto descritivo (ex.: "Núcleo de Braga"), decorativas com alt="" — AccessMonitor: "Constatei que todas as imagens da página têm o necessário equivalente alternativo em texto" em todas as páginas.
• Os textos alternativos dos conteúdos são obrigatórios no backoffice (ex.: hero_slides.alt NOT NULL).

N/A 5.2

• O site não apresenta gráficos resultantes de análise de dados. O mapa de Portugal é um elemento de navegação com lista alternativa de núcleos em texto.

Sim 5.3

• As imagens-link (logótipo) têm nome acessível; não existem outras ligações compostas apenas por imagem sem texto (verificado com script em todas as páginas da amostra).
• Os pontos do mapa de Portugal são ligações com aria-label "Ir para o Núcleo de …".

Sim 6.1

• Texto normal com contraste ≥ 4,5:1: as cores de texto e fundo são tokens HSL centralizados (index.css), escolhidos para cumprir este rácio.
• Texto branco sobre imagens assenta numa camada escura (overlay) e numa cor de fundo escura sólida, também calculável por validadores.
• AccessMonitor: sem práticas não aceitáveis de contraste (nível AA) nas páginas da amostra — ver relatório automático.

Sim 6.2

• Títulos e texto grande com contraste ≥ 3:1 (os títulos usam as mesmas cores de texto, acima de 4,5:1).

Sim 7.1

• O único vídeo da amostra (Pequenas Grandes Vitórias — "Acreditar na inclusão como direito") usa o leitor incorporado do YouTube, operável com rato e teclado (Tab, Espaço, setas); nenhum vídeo arranca automaticamente.
• Vídeos alojados no site usam <video controls> nativo do navegador.

Não 7.2

• O vídeo publicado no YouTube tem apenas legendas automáticas (geradas pelo YouTube) e não tem transcrição textual revista.

Nota: Ação corretiva prevista: rever as legendas do vídeo no YouTube (ou publicar transcrição) e exigir legendas/transcrição para todos os vídeos novos.

Sim 8.1

• Com a CSS removida, todos os elementos alinham à esquerda (ver captura).

Sim 8.2

• Sem CSS, a ordem é lógica: link "Saltar para o conteúdo principal", logótipo, menu, conteúdo principal, rodapé — a ordem do DOM corresponde à ordem visual.

Sim 8.3

• Sem CSS reconhecem-se títulos, listas, ligações, botões e campos de formulário — marcação semântica HTML5 (header, nav, main, section, footer, h1–h3, ul/li).

Sim 8.4

• Sem CSS não se perde informação: não há conteúdo relevante injetado por CSS (imagens de fundo são decorativas e o texto existe no HTML).

Sim 8.5

• A paginação usa CSS (flexbox/grid); não há elementos <table> usados para layout (verificado com script).

Sim 9.1

• Modal de encomenda (Loja): ao abrir, o foco vai para o primeiro campo do formulário dentro do modal.
• Menu móvel: ao abrir, o foco vai para o botão "Fechar menu" dentro do diálogo.

Sim 9.2

• Com o modal ou o menu móvel abertos, Tab/Shift+Tab circulam apenas pelos elementos do diálogo (testado com 30–40 tabulações sem sair do diálogo).

Sim 9.3

• Ambos têm botão "Fechar" visível e fecham com a tecla Esc.

Sim 9.4

• Ao fechar (Esc ou botão), o foco volta ao elemento que abriu o diálogo: botão "Encomendar" ou botão "Abrir menu" (testado com teclado e com rato).

Não 10.1

• Foram testados os 23 PDF alojados no site (Biblioteca e documentos institucionais): 16 permitem extrair o texto; 6 são digitalizações sem camada de texto (Ata n.º 43, Adenda à Ata n.º 43, Estatutos, Balanço 2021, Demonstração de Resultados 2021, Relatório de Atividades e Apresentação AG 2021) e 1 ficheiro está corrompido (Relatório de Atividades 2023).

Nota: Ação corretiva prevista: substituir os PDF digitalizados pelos originais com texto (ou versões com OCR) e voltar a carregar o Relatório de Atividades 2023.

Sim 1.1

• Na página inicial, sem fazer scroll, vê-se: "Associação Nacional — IPSS desde 2010", "Apoiamos as famílias", "Trabalhamos numa parceria de pais e profissionais — de norte a sul de Portugal e ilhas" e as ações principais (Juntar-me, Conhecer núcleos, Linha SOS, Linha da Empregabilidade).

Sim 1.2

• As siglas são explicadas no texto na primeira ocorrência (ex.: "Centro de Apoio à Vida Independente (CAVI)").
• Página Glossário (/glossario), ligada no rodapé de todas as páginas, com 19 siglas e termos técnicos (CAVI, MAVI, SAVI, IPSS, ONGPD, NEE, CLDS, RGPD, consignação do IRS, etc.).

Não 1.3

• As notícias e a Declaração de Acessibilidade indicam a data, mas a maioria dos blocos de conteúdo das páginas institucionais não apresenta data de atualização.

Nota: Ação corretiva prevista: mostrar a data da última atualização (campo updated_at do backoffice) nos blocos de conteúdo.

Sim 1.4

• O rodapé de todas as páginas identifica a entidade ("Pais em Rede — Associação Nacional de famílias de pessoas com deficiência e incapacidade", NIF) e tem ligação para a página Contactos, telefones e emails.

Sim 2.1

• Texto do corpo em Source Serif 4 com 18–20 px (≥ 12 pt); escalável com o zoom do navegador e com o painel de acessibilidade do site (até 200%).

Sim 2.2

• Informação secundária (datas, autores, tipo de documento, notas) com pelo menos 14 px (≥ 10 pt): o tamanho mais pequeno do sistema tipográfico (text-xs) passou a 14 px.

Sim 2.3

• Os blocos de texto têm largura máxima de leitura (contentores max-w-3xl/4xl/5xl); medição com script: linhas de texto corrido até ~95 caracteres a 1280 px de largura.

Sim 2.4

• Entrelinha de 1,5 a 1,75 vezes o tamanho da letra em todo o texto corrido (configuração tipográfica global do Tailwind: base/xl 1,6; lg 1,75; sm/xs/2xl 1,5).

Sim 3.1

• O menu principal tem 9 opções de primeiro nível; nenhum submenu tem mais de 5 opções.

Sim 3.2

• O cabeçalho com o menu é fixo no topo (sticky) e igual em todas as páginas; a opção da secção atual fica destacada (fundo azul claro) e tem aria-current="page".

Sim 3.3

• As ligações no texto corrido estão sublinhadas e têm contraste ≥ 4,5:1; o mesmo estilo é usado em todo o site. O painel de acessibilidade permite ainda sublinhar todas as ligações.

Sim 4.1

• Os documentos longos (Declaração de Acessibilidade, Política de Privacidade) têm no topo um índice com ligações internas para as secções.

Sim 4.2

• Layout responsivo: sem barra de deslocamento horizontal a 320, 375 e 1280 px (verificado com script em todas as páginas da amostra).

Sim 5.1

• Os submenus abrem também com clique/teclado no botão próprio; os nomes dos núcleos no mapa estão também numa lista de ligações; não há ações disponíveis apenas com hover.

Não 5.2

• Botões, campos e ligações autónomas têm 44 px (pontos dos carrosséis, links do rodapé, botões da equipa, menu móvel).
• Exceções: botões de submenu do menu de computador (24 × 44 px), pontos do mapa de Portugal (~19 px, com lista alternativa) e ligações dentro de texto corrido.

Nota: Os 24 px cumprem o critério WCAG 2.5.8 (AA), mas não os 44 px pedidos pela checklist. Ação prevista: rever o desenho do menu de computador.

Não 5.3

• O botão "Associar-me" do cabeçalho está presente em todas as páginas além do botão de ação principal de cada página (ex.: "Encomendar", "Seguinte").

Sim 5.4

• Botões com forma de pílula, cor de fundo e mudança de estado ao passar o rato/receber foco; cartões clicáveis com sombra e elevação; ícones com rótulo.

Sim 1.1

• Nos formulários de adesão a sócio e de encomenda, a ordem de tabulação segue a ordem de preenchimento (ordem do DOM = ordem visual; sem tabindex positivo).

Sim 1.2

• O formulário de adesão a sócio, que teria mais de 2 ecrãs, está dividido em 4 passos: Dados pessoais, Familiar com deficiência, Dados para emissão de recibo, Adesão.

Sim 1.3

• Indicador de passos no topo do formulário (lista ordenada com nome de cada passo e aria-current="step" no passo atual); os passos já concluídos são botões que permitem voltar, e há botão "← Voltar".

Sim 2.1

• Campos de dados curtos (telefone, código postal, NIF, quantidade) têm largura reduzida; campos de texto livre ocupam a largura total.

Sim 2.2

• Revelação progressiva: os campos seguintes aparecem à medida que os anteriores são preenchidos, e os dados de recibo só aparecem se a pessoa desmarcar "Usar os dados pessoais acima"; os novos campos são anunciados aos leitores de ecrã.

Sim 2.3

• Etiquetas curtas ("Nome", "Apelido", "Email", "Telefone"); as explicações aparecem como nota por baixo do campo.

Sim 2.4

• Asterisco vermelho junto à etiqueta, nota em texto no início do formulário e aria-required="true" para tecnologias de apoio.

Sim 3.1

• Durante o envio, o botão muda para "A enviar..." e fica desativado.

Sim 3.2

• Após o envio é mostrada uma mensagem de confirmação (role="status", anunciada pelos leitores de ecrã), e é enviado um email de confirmação para o endereço indicado.

Sim 4.1

• Antes de submeter, é possível voltar a qualquer passo anterior e corrigir os dados; os valores introduzidos mantêm-se.

N/A 4.2

• Os formulários não têm ações destrutivas (não há eliminação de dados pelo utilizador).

Sim 4.3

• Mensagens de erro imediatamente por baixo do campo de origem, a vermelho, com contorno vermelho no campo, role="alert" e aria-describedby.

Sim 4.4

• As mensagens dizem o que fazer: "Preencha «Nome» antes de continuar.", "Introduza um email válido, no formato nome@exemplo.pt", "Código postal inválido — use o formato 1234-567.", "O NIF deve ter 9 dígitos e o dígito de controlo correto (ex.: 123456789)."