Back to the statement
Evidence from the manual evaluation
Esta página reúne as evidências da avaliação manual referida na secção II.B da Declaração de Acessibilidade e Usabilidade deste sítio, atualizada a . As listas de verificação são as publicadas pela ARTE, I.P. no Kit do Selo de Usabilidade e Acessibilidade.
Um requisito conta como satisfeito quando há uma observação concreta que o sustente. «Não aplicável» significa que o requisito trata de uma função que este sítio não tem — e a razão está escrita ao lado, porque um «não aplicável» sem justificação é uma forma de subir a percentagem sem subir a acessibilidade. «Carece de verificação humana» é a resposta honesta para o que só se confirma com uma pessoa e a sua tecnologia de apoio.
A pontuação de cada lista segue a fórmula da folha de recolha de evidências da ARTE: requisitos satisfeitos a dividir pelo total de requisitos menos os não aplicáveis. O mínimo exigido pelo Selo é 75% em cada lista.
Lista «10 aspetos críticos de acessibilidade funcional para sítios Web»
É a lista de verificação a que se refere o artigo 9.º, n.º 1, alínea b) do Decreto-Lei n.º 83/2018: a avaliação manual pericial que acompanha a avaliação automática.
24 de 26 requisitos aplicáveis satisfeitos (92%) — 27 requisitos na lista, 1 não aplicáveis a este sítio.
| Requisito | Veredicto | Evidência |
|---|---|---|
| 1.1 O menu de navegação deve estar estruturado como uma lista de opções | Satisfaz | O menu principal é uma <ul> com role="list" e cinco <li> (components/Nav.tsx), e a árvore de acessibilidade do Chrome devolve role=list para #nav-menu ul. O rodapé acrescenta dois menus igualmente em lista, com 4 e 6 opções, cada um em <nav> com aria-label próprio. |
| 1.2 É possível selecionar as opções e as subopções do menu quer com rato quer com teclado | Satisfaz | A 1280px o clique do rato em «Writing» e o Enter sobre «Diagnostic» navegam ambos. A 390px o botão do menu mede 44x44, abre com Enter, move o foco para a primeira opção, o Tab percorre as cinco (Work, Services, Writing, Diagnostic, Get in touch), e Escape fecha devolvendo o foco ao botão; o seletor de idioma abre com ArrowDown e percorre as seis opções com as setas. |
| 1.3 As imagens-link, caso existam no menu, devem ter o correspondente equivalente alternativo em texto | Satisfaz | As únicas imagens-link do menu são os dois logótipos: <img alt=""> dentro de <a aria-label>, cujo nome acessível lido do Chrome é «Tiago Peres — página inicial», no cabeçalho e no rodapé. As bandeiras do seletor de idioma são aria-hidden e cada opção traz o nome do idioma em texto. |
| 2.1 Existe um título <h1> marcado na página | Satisfaz | Varrimento às 260 páginas exportadas em out/: todas têm exatamente um <h1>. Nenhuma tem zero e nenhuma tem dois. |
| 2.2 Existe uma marcação hierarquizada de títulos e subtítulos na página (<h1>...<h6>) | Satisfaz | Nas mesmas 260 páginas não há um único salto de nível na sequência de <h1> a <h6> — nenhum h2 seguido de h4, nenhum h1 seguido de h3. O axe-core não reporta heading-order em nenhuma delas. |
| 3.1 As células que constituem os cabeçalhos da tabela estão marcadas com o elemento <th> | Satisfaz | As 108 tabelas do export têm os cabeçalhos marcados com <th>, num total de 792 elementos <th>; nenhuma tabela fica sem eles. As quatro tabelas que acompanham os gráficos usam <th scope="row"> nas linhas. |
| 3.2 A legenda da tabela está marcada com o elemento <caption> | Satisfaz | As 108 tabelas do export têm <caption>: 108 legendas para 108 tabelas, zero sem legenda. As legendas são escritas no markdown do artigo como <!-- caption: ... --> e convertidas em <caption> real na construção. |
| 4.1 Ao clicar com o rato na etiqueta, o cursor surge no respetivo campo de edição | Satisfaz | Os cinco campos do formulário de contacto têm <label for> a apontar para o id respetivo (cf-name, cf-email, cf-company, cf-budget, cf-message), e clicar na etiqueta «Nome» coloca o cursor em #cf-name. No diagnóstico cada resposta é um <input type="radio"> dentro do seu <label>, cuja área ativa mede entre 51x44 e 133x44 px. |
| 4.2 É possível identificar os campos de preenchimento obrigatório quando se usa apenas um leitor de ecrã | Satisfaz | O nome acessível devolvido pelo Chrome para os três campos obrigatórios é «Nome(obrigatório)», «Email(obrigatório)» e «O que está a construir?(obrigatório)», com a propriedade required=true; os opcionais dizem «(opcional)». A marcação é textual e não depende de cor nem de símbolo. |
| 4.3 É possível localizar e ler as mensagens de erro usando apenas um leitor de ecrã | Satisfaz | Submeter o formulário vazio produz um resumo com role="alert" que recebe o foco («A mensagem não foi enviada. Verifique o seguinte:») e liga cada erro ao seu campo por href="#cf-name", "#cf-email" e "#cf-message". Cada campo fica com aria-invalid="true" e a sua descrição acessível passa a ser a mensagem — lida da árvore do Chrome como «Indique o seu nome.» |
| 5.1 A imagem ou gráfico tem um equivalente alternativo em texto curto e correto | Não satisfaz | Das 924 ocorrências de alt não vazio no export, 662 passam dos 100 caracteres — 502 textos distintos, em 195 ficheiros, a mais longa com 329 caracteres. São capturas de ecrã de conversas em que o alt transporta o conteúdo, e o padrão já provado nos quatro gráficos (alt curto mais descrição longa num <details> ligado por aria-describedby) ainda não foi aplicado aos artigos. |
| 5.2 O gráfico é acompanhado de uma descrição longa | Satisfaz | Os quatro gráficos do sítio — chart-transactions, chart-finality, chart-tokenization e cap-chart — apontam por aria-describedby para um <details> que contém a tabela de dados que lhes deu origem, com <caption> e <th>. Verificado nas seis versões linguísticas de the-rail-the-robots-will-pay-on e de who-pays-when-the-ai-is-wrong. |
| 5.3 As imagens-link têm um equivalente alternativo correto | Satisfaz | Há 664 hiperligações compostas apenas por imagem ou SVG no export e todas as 664 têm nome acessível, por aria-label, aria-labelledby ou alt não vazio; zero ficaram sem nome. Inclui os logótipos do cabeçalho e do rodapé e os oito logótipos de clientes da faixa animada. |
| 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 | Satisfaz | O axe-core correu num Chromium real sobre as 260 páginas exportadas e não devolveu qualquer violação, incluindo a regra color-contrast; repetido com o menu móvel, o seletor de idioma, a lightbox, o resultado do diagnóstico e o formulário em erro abertos, também sem violações. O texto corrente mais fraco é --muted #656c7c, a 5,04:1 sobre --bg #fafafa e 5,26:1 sobre branco; no rodapé escuro, --panel-muted #9aa0ac mede 7,31:1 sobre #000e29. |
| 6.2 O rácio de contraste entre a cor do texto de tamanho grande (maior ou igual que 18 pontos ou maior ou igual que 14 pontos negrito) e a cor do fundo é superior a 3:1 | Satisfaz | O <h1> da página inicial, a 80px e peso 700, mede 17,34:1 sobre #fafafa. O branco do botão de ação principal mede 5,62:1 sobre a marca True Blue #0466c8 e 14,64:1 sobre #002855, ou seja acima de 3:1 em toda a extensão do gradiente que o pinta. |
| 7.1 Deve ser possível ativar os botões de controlo do leitor quer com o rato quer com o teclado | Satisfaz | Não existe um único atributo autoplay no export e nenhum media arranca sozinho. Os botões do leitor de narração medem 44x44 e têm nome («Play», «Back 10 seconds», «Forward 10 seconds», «Playback speed: 1×»), o cursor de posição é um <input type="range"> de 282x44 com etiqueta «Seek»: Enter no botão de reprodução inicia e volta a parar o áudio, o clique do rato faz o mesmo, e a seta direita move o cursor. |
| 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 | Não satisfaz | O artigo five-music-engines-one-adapter incorpora dois <audio> com voz cantada e nenhum dos dois tem transcrição nem legendas: cada um tem apenas uma <figcaption> descritiva ligada por aria-describedby, que diz o que é a faixa, não o que é cantado. A narração dos artigos não levanta o mesmo problema, porque o texto lido está na própria página. |
| 8.1 Quando se retira a CSS, todos os elementos HTML devem alinhar à esquerda | Satisfaz | Removidas todas as folhas de estilo e os atributos style em oito rotas (inicial, blogue, artigo, diagnóstico, glossário, evidências, serviços e /pt/), os únicos elementos que não alinham à esquerda são <button>, <th> e <caption>, que o próprio navegador centra por omissão. Nenhuma regra de autor sobrevive a centrar ou a alinhar à direita. |
| 8.2 Quando se retira a CSS, a informação aparece numa ordem lógica | Satisfaz | Sem CSS, a ordem do DOM nas oito rotas testadas é a ordem de leitura: ligação de salto, menu, seletor de idioma, <h1>, parágrafo de entrada, índice da página e depois as secções pela ordem em que aparecem no ecrã. Numa página de artigo, o leitor de narração e a imagem de topo vêm antes do corpo, como na versão com estilos. |
| 8.3 Quando se retira a CSS, deve ser possível reconhecer a semântica dos diversos elementos | Satisfaz | Sem CSS as páginas continuam a expor a sua estrutura em elementos nativos: numa página de artigo contam-se 1 main, 1 header, 1 footer, 4 nav, 12 h2, 8 ul/ol com 43 li, 3 table com 3 caption e 21 th, 3 figure com figcaption e 7 details/summary. As listas do menu levam role="list" para sobreviverem à supressão do marcador. |
| 8.4 Quando se retira a CSS, a informação relevante permanece visível | Satisfaz | Não há informação transportada por CSS: a única background-image da folha de estilo é a seta decorativa dos <select>, e todo o content gerado em ::before/::after é decorativo (aspas, + e −, visto, ponto separador). O que fica oculto sem estilos são apenas painéis fechados pelo atributo hidden — o seletor de idioma, os três passos fechados do diagnóstico, as páginas seguintes do índice do blogue — cada um alcançável pelo seu próprio controlo. |
| 8.5 A maquetização da página é feita sem recorrer ao elemento <table> | Satisfaz | As 108 tabelas do export são todas tabelas de dados, com <th> e <caption>, e nenhuma tem role="presentation". A composição gráfica é feita com <main>, <section>, <article>, <aside> e <div> em grelha e flexbox. |
| 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 | Satisfaz | A lightbox é um <dialog> nativo aberto com showModal(). Abrindo-a pelo botão «Enlarge image» de uma imagem de artigo, o foco fica no botão «Close» dentro da caixa, verificado num Chromium real. |
| 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 | Satisfaz | Com a caixa aberta, dialog.matches(':modal') é verdadeiro; tentar focar por programa um elemento de fora (uma opção do seletor de idioma) deixa o foco dentro da caixa. Dez Tab consecutivos só passam pela região de deslocamento da imagem e pelo botão «Close» — nenhum elemento exterior é alcançado. |
| 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 | Satisfaz | A tecla Escape fecha a caixa (dialog.open passa a falso) e o botão «Close», que é o primeiro elemento focado ao abrir, fecha-a também. Ambos verificados num Chromium real. |
| 9.4 Quando a caixa de diálogo fecha, o foco (cursor do Browser) deve voltar ao elemento interativo que o invocou | Satisfaz | Depois de fechar, quer por Escape quer pelo botão «Close», o foco volta ao botão «Enlarge image» que a invocou, comportamento nativo do <dialog> confirmado pelas duas vias. |
| 10.1 Nos ficheiros PDF é possível, no mínimo, extrair o conteúdo textual para formato TXT | Não aplicável | Não existe um único ficheiro PDF neste sítio: a procura por *.pdf em public/ e em out/ devolve zero resultados. As três ligações para PDF que os artigos contêm apontam para sítios de terceiros (Citi, veryinteractive.net e familyofsaintsharbel.org), cujos ficheiros este sítio não publica nem controla. |
Wider than the screen — scroll the table sideways to see every column.
Fonte da lista: amagovpt.github.io/kit-selo/checklists/checklist-10aspetos
Lista «Conteúdo»
Exigida para o Selo Bronze. Trata da clareza, da legibilidade e da estrutura do conteúdo — do que torna uma página utilizável antes de a tornar bonita.
16 de 17 requisitos aplicáveis satisfeitos (94%) — 17 requisitos na lista, todos aplicáveis a este sítio.
| Requisito | Veredicto | Evidência |
|---|---|---|
| 1.1 O sítio Web apresenta um resumo breve do seu propósito, visível sem se fazer scroll | Satisfaz | A 1280x800 o <h1> da página inicial («I help teams and founders put AI into production.») termina a 514px e o parágrafo que diz a quem se dirige termina a 706px, ambos dentro do primeiro ecrã. A 390x844 esse parágrafo termina a 575px em inglês e a 602px em português, também sem deslocamento. |
| 1.2 Os termos mais complexos têm uma definição agregada | Não satisfaz | O glossário em /glossary/ publica 12 termos com <dfn> e uma lista de definições, e os artigos plantam 168 ligações de primeira menção e 54 <abbr>. Mas sete termos técnicos continuam a ser usados sem definição no texto visível: token (96 ocorrências em 42 páginas), MVP (96 em 30), embeddings (39 em 11), guardrails (33 em 13), latency (18 em 10), prompt injection (4 em 2) e quantization (3 numa). Nenhuma frase do repositório os define, pelo que não puderam entrar no glossário. |
| 1.3 Cada bloco de conteúdo contém a sua data de atualização | Satisfaz | 258 das 260 páginas exportadas trazem uma data dentro de <main> — as duas exceções são as duas cópias da página 404: os artigos a sua própria data de revisão em <time>, as restantes a data partilhada do componente ContentReviewed. Mede 14,4px (10,8pt), cerca de dois pontos abaixo do corpo de 17px (12,75pt), a --muted #656c7c, que dá 5,04:1 sobre o fundo da página. |
| 1.4 A informação sobre a entidade responsável pelo conteúdo está em todas as páginas | Satisfaz | Nas 260 páginas exportadas o rodapé traz o nome da entidade responsável pelos conteúdos («© 2026 Tiago Peres», mais a função e a localização) e uma hiperligação para a secção de contacto, cujo href termina em #contact: zero páginas sem um e zero sem a outra. |
| 2.1 O tipo de letra do corpo do documento é adequado e o tamanho da letra é, no mínimo, de 12 pontos | Satisfaz | O texto corrente dos artigos mede 17,28px (12,96pt) em Roboto e o corpo do documento 17px (12,75pt), acima do mínimo de 12 pontos. Pondo o tamanho base do navegador em 24px e em 32px (por CDP Page.setFontSizes), o texto passa a 25,92px e 34,56px: a raiz usa clamp em rem, pelo que escala a um para um com a definição do leitor em vez de a substituir. |
| 2.2 A informação secundária (datas, autores) utiliza, no mínimo, um tamanho de letra de 10 pontos | Satisfaz | A informação secundária respeita o piso de dez pontos: data e autor a 14,4px (10,8pt), legenda de tabela a 14,08px (10,56pt), etiquetas e sobretítulos a 13,44px (10,08pt). Os 24 elementos <code> dentro de células de tabela que computavam 12,95px (9,72pt) — porque `.prose code { font-size: 0.88em }` se multiplicava pelos 14,72px da célula — deixaram de encolher dentro da célula: medidos no navegador em /blog/ai-agents-mcp-framework-landscape/ e em /pt/blog/feature-request-to-pull-request/, computam agora 14,72px, que são 11,04 pontos. |
| 2.3 Blocos e linhas de texto com largura não superior a 100 caracteres | Satisfaz | Medindo os caracteres de cada linha efetivamente desenhada, com retângulos de Range por caráter em vez de dividir a largura da caixa pela largura média do glifo, em 31 rotas das seis línguas e a 390, 1280, 1920 e 2560px, nenhuma linha passa dos 100 caracteres. A mais densa encontrada tem 98, no parágrafo de abertura de um endereço em /diagnostic/. A 8 de outubro de 2026, as cinco páginas que não são ensaios (sobre, aviso de privacidade, glossário, esta declaração e as suas evidências) passaram para a coluna mais larga do diagnóstico, com o texto corrido preso a uma medida de 40rem e as células e a legenda das tabelas de evidências a 36rem; repetida a medição nessas trinta rotas (cinco páginas em seis línguas), às mesmas quatro larguras, nenhuma linha passa dos 100 caracteres: a mais densa tem 94, numa célula das tabelas de evidências, e 93 no aviso de privacidade em inglês. No mesmo dia, os ensaios passaram para a mesma moldura, com a coluna de leitura centrada e presa a 42rem e as legendas de imagens e de tabelas à sua medida de 70ch; medidas as 198 rotas dos 33 ensaios em seis línguas a 1280px, e seis deles também a 390, 1920 e 2560px, nenhuma linha passa dos 100 caracteres: a mais densa tem 99, num parágrafo de «Is It Actually an Agent?» em inglês e em dois ensaios em francês. |
| 2.4 O espaçamento entre linhas não é inferior a 1.5x o tamanho da letra | Satisfaz | Varrimento às 259 rotas a 1280px: nenhum bloco de texto corrido (p, li, dd, dt, blockquote, figcaption, td, th, caption, summary) tem entrelinha inferior a 1,5. O valor mais baixo é exatamente 1,500, em .post-cta--top .post-cta__sub, e o corpo dos artigos está a 1,72; os títulos h1 a h3 usam 1,15, que é o espaçamento próprio de tipo de display e não de um bloco de texto. |
| 3.1 Nenhum nível de navegação tem mais de 9 opções | Satisfaz | O menu principal tem 5 opções, os dois menus do rodapé têm 4 (serviços) e 6 (restantes), e o seletor de idioma tem 6: nenhum nível de navegação chega às 9. Os índices dentro de página, cujo maior tem 12 entradas no glossário, são índices do próprio documento e não um nível da estrutura de navegação. |
| 3.2 A navegação principal está sempre visível e sempre no mesmo local | Satisfaz | A barra de navegação é position: sticky; top: 0 e está nas 260 páginas exportadas, sempre no mesmo lugar. A posição atual é marcada com aria-current e desenhada com peso 600 e sublinhado de 2px, não só com cor: /diagnostic/ e /services/mvp/ dão aria-current="page" e uma página de artigo dá aria-current="true" em «Writing». |
| 3.3 As hiperligações de texto não devem ser diferenciadas apenas com base na cor | Satisfaz | Em 52 rotas amostradas, as 348 hiperligações em texto corrido estão todas sublinhadas; a única exceção é .diag__essay-link, que é uma pastilha com contorno próprio de 4,09:1 e por isso não se distingue apenas pela cor. O azul das ligações (--accent-ink #034c96) mede 8,47:1 sobre branco e as do rodapé são --panel-ink a 16,48:1 sobre #000e29, também sublinhadas. |
| 4.1 Os documentos longos têm um índice no topo com hiperligações internas para o mesmo | Satisfaz | Das 251 rotas com mais de três ecrãs de altura a 1280x900, 245 trazem um índice no topo com hiperligações internas — nav.toc nos artigos e nas páginas longas, nav.declaracao__indice nas seis Declarações. As seis exceções são os índices de escrita (/blog/ e as suas cinco traduções), cujos únicos dois <h2> são um rótulo invisível e o título da faixa final, e que abrem com filtros por tema e paginação em vez de um índice. |
| 4.2 O layout do sítio Web é adaptável a plataformas móveis sem necessidade de efetuar varrimento horizontal | Satisfaz | Varrimento às 260 rotas a 390px: zero páginas com barra de deslocamento horizontal. A 320px, equivalente a 400% de ampliação, a página de artigo também não a tem (scrollWidth 320 para clientWidth 320); as tabelas de dados e os blocos de código deslocam-se dentro da sua própria caixa, que está na ordem de tabulação. |
| 5.1 Não existem elementos interativos acionados apenas com a passagem do rato (hover) | Satisfaz | Nenhum elemento interativo aparece só com o rato. A pastilha de lupa que abre uma imagem está visível em repouso com opacidade 1, tanto num contexto de toque (150x33, com a palavra) como no escritório (disco de 28x28), e o botão que abre a imagem cobre-a por inteiro (746x420 medidos num artigo a 1280px, onde a imagem de abertura toma a moldura inteira; 288x163 a 320px). As regras de :hover da folha de estilo que mudam um controlo têm todas o par :focus-visible ou :focus-within, e a faixa de logótipos e o carrossel têm botão de pausa em vez de dependerem do rato. |
| 5.2 Os elementos interativos têm uma dimensão mínima de 44px CSS (44 pontos) (vertical e horizontal) | Satisfaz | Varrimento às 260 rotas a 390px: os controlos autónomos medem todos 44px ou mais — pastilhas de resposta do diagnóstico entre 51x44 e 133x44, botão do menu 44x44, botões do leitor 44x44, cursor de posição 282x44, opção do seletor de idioma 77x44, ligações do rodapé com min-height 44px. Os <input> de 1x1 detetados são os radios escondidos sob a sua etiqueta de 44px e o campo-armadilha anti-robôs, que é aria-hidden e tem tabindex -1; ficam de fora as ligações em texto corrido, que mantêm a entrelinha do texto onde estão. |
| 5.3 Há apenas um botão de ação principal por página e o mesmo encontra-se destacado | Satisfaz | Contando fora dos scripts, nenhuma das 260 páginas exportadas tem mais do que um .btn--primary: 230 têm exatamente um e 30 (Declaração, evidências, diagnóstico, glossário e aviso de privacidade) não têm nenhum. O botão principal destaca-se em branco sobre o gradiente --grad, entre 5,62:1 e 14,64:1. |
| 5.4 Elementos gráficos interativos têm de aparentar ser clicáveis | Satisfaz | As imagens que abrem em tamanho real trazem em repouso uma pastilha escura com uma lupa no canto — 28x28 no escritório, 150x33 com a palavra em ecrãs de toque — e a área ativa é um <button> real que cobre a imagem inteira. Os logótipos de clientes são ligações que recuperam a cor em :hover e em :focus-visible, e os quatro passos do diagnóstico são botões com contorno e disco numerado. |
Wider than the screen — scroll the table sideways to see every column.
Fonte da lista: amagovpt.github.io/kit-selo/checklists/checklist-conteudo
Lista «Transação»
Exigida para o Selo Prata. Trata dos formulários e de tudo o que o visitante tem de preencher, confirmar ou corrigir.
12 de 13 requisitos aplicáveis satisfeitos (92%) — 13 requisitos na lista, todos aplicáveis a este sítio.
| Requisito | Veredicto | Evidência |
|---|---|---|
| 1.1 A sequência de tabulação entre campos segue a sequência de preenchimento | Satisfaz | No formulário de contacto o Tab segue cf-name, cf-email, cf-company, cf-budget, cf-message e «Enviar mensagem», que é a ordem por que os campos aparecem e se preenchem. No diagnóstico segue o seletor de assunto, os quatro passos e depois pergunta 1, pergunta 2, pergunta 3 e «Seguinte». Não há um único tabindex positivo em nenhuma das duas páginas. |
| 1.2 Os formulários com mais de 2 ecrãs de altura devem ser distribuídos por várias páginas | Satisfaz | O formulário de contacto mede 580px de altura, 0,64 de um ecrã de 900px. O diagnóstico de doze perguntas está repartido por quatro passos de três perguntas cada: o passo aberto mede 557px e, contando a barra de passos, ocupa 0,75 de ecrã — abaixo dos dois ecrãs que a exigência permite. |
| 1.3 Os formulários com mais de uma página têm a sequência de passos ilustrada | Satisfaz | O diagnóstico abre com «Passo 1 de 4» e uma <ol> de quatro botões, cada um com o nome do endereço e o seu estado («Julgamento — 0 de 3 respondidas»), o atual marcado com aria-current="step". Clicar num passo anterior reabre-o com as três respostas intactas e leva o foco ao <h2> desse passo. |
| 2.1 O tamanho dos campos deve refletir o tamanho previsível dos dados | Satisfaz | O formulário não tem nenhum campo de formato fixo — não pede telefone, código postal nem número de contribuinte — pelo que não há largura estrita a respeitar. O único campo cujo conteúdo esperado é de outra ordem, a mensagem, é o que é diferente: 432x120px, contra os 208x45px dos quatro campos curtos, que ficam dois a dois na mesma linha. |
| 2.2 É usada revelação progressiva em vez de campos inativos | Satisfaz | Não há um único controlo de formulário desativado no export: zero atributos disabled em input, select, textarea ou button, e o único aria-disabled encontrado é o "false" do botão de envio. O que depende de uma escolha é revelado em vez de ser mostrado inativo — os três passos fechados do diagnóstico e os painéis de explicação das perguntas estão com o atributo hidden e abrem pelo seu próprio controlo. |
| 2.3 As legendas dos campos são breves e claras | Satisfaz | As etiquetas são curtas: «Nome», «Email», «Empresa», «Orçamento / prazo», «O que está a construir?». A única instrução mais longa está num bloco paralelo (span.form-hint, «Umas linhas sobre o problema que quer resolver. Mesmo em bruto serve.») ligado ao campo por aria-describedby, fora da etiqueta; no diagnóstico, a explicação de cada pergunta abre num <dl> próprio, a partir de um botão ao fim da linha. |
| 2.4 Campos obrigatórios devem ser claramente indicados como tal | Satisfaz | A obrigatoriedade está escrita por extenso na etiqueta e entra no nome acessível lido do Chrome: «Nome(obrigatório)», «Email(obrigatório)» e «O que está a construir?(obrigatório)», com a propriedade required=true; os campos opcionais dizem «(opcional)». Não há dependência de cor nem de asterisco. |
| 3.1 Em ações longas, o sistema deve indicar o que está a acontecer | Satisfaz | Com o envio a decorrer, o botão passa a dizer «A enviar…», ganha aria-disabled="true" e a região role="status" do formulário anuncia «A enviar…». O botão não é desativado, pelo que o foco de quem carregou em Enter não se perde. |
| 3.2 Deve ser confirmado o sucesso da transação/envio de informação | Não satisfaz | Aparece uma confirmação — «Mensagem a caminho.» — que recebe o foco, é anunciada por role="status" e escreve #thanks no endereço. Mas o pedido é feito com mode: 'no-cors' (components/ContactForm.tsx, linha 284) e o Apps Script devolve {ok:true} incondicionalmente, chamando reply() também quando o Turnstile rejeita (scripts/contact-form.gs, linha 52): a mensagem confirma que o pedido saiu do navegador, não que a transação teve êxito, e uma rejeição é indistinguível de uma entrega. |
| 4.1 A informação já introduzida deve poder ser corrigida a qualquer momento | Satisfaz | Todos os campos do formulário ficam editáveis até ao envio e nenhum é bloqueado depois de preenchido. No diagnóstico, voltar a um passo anterior devolve as três respostas intactas e qualquer uma pode ser mudada, incluindo depois de o resultado já estar calculado — verificado num Chromium real. |
| 4.2 As ações destrutivas nunca devem ser permanentes; deve ser sempre possível desfazer a operação | Satisfaz | A única ação destrutiva do sítio é o «Recomeçar» do diagnóstico, que apaga as doze respostas. No seu lugar fica uma mensagem com role="status" — «As suas doze respostas foram apagadas. Anular» — e carregar em «Anular» repõe exatamente os mesmos resultados, verificado com 6/6, 6/6, 6/6, 6/6 antes e depois. |
| 4.3 As mensagens de erro são claramente identificadas junto aos campos de origem | Satisfaz | Cada mensagem de erro fica junto ao seu campo, com id próprio, ligada por aria-describedby, e o campo passa a aria-invalid="true". Por cima há uma lista-resumo com role="alert" que recebe o foco e cujas entradas são hiperligações para #cf-name, #cf-email e #cf-message. |
| 4.4 As mensagens de erro devem mostrar os passos concretos para a resolução dos mesmos | Satisfaz | As mensagens dizem o passo a dar e não expõem mecanismos internos: «Indique um email, na forma nome@empresa.com.» e «Escreva uma linha ou duas sobre o que está a construir.» A do Turnstile dá o passo e a alternativa: «Falta concluir a verificação de segurança acima. Marque a caixa e envie outra vez. Se a verificação não chegar a aparecer, pode estar a ser bloqueada pelo navegador — nesse caso, contacte-me no LinkedIn.» |
Wider than the screen — scroll the table sideways to see every column.
Fonte da lista: amagovpt.github.io/kit-selo/checklists/checklist-transacao