Every image, icon, chart, or other non-text element must have a text alternative that serves the same purpose as the original.
Grelha de Auditoria WCAG 2.2
59 critérios de sucesso WCAG 2.2 (todo o Nível A + Nível AA, mais 2 de Nível AAA), cobrindo todos os critérios obrigatórios pela EAA. A cobertura total AAA e a exportação de auditoria estão disponíveis no Gerador de Grelha Pro.
O que é isto?
Esta é uma lista de verificação abrangente do WCAG 2.1 AA que cobre todos os 50 critérios de sucesso. É a lista mais completa da plataforma e a base de uma auditoria completa de acessibilidade.
Quando preciso disto?
Utilize esta lista ao realizar uma auditoria minuciosa de acessibilidade do seu produto, ou quando precisar de demonstrar conformidade especificamente com o WCAG 2.1 AA. Para a conformidade com o EAA, utilize as listas específicas de setor que incluem requisitos adicionais do EAA.
- 1Trabalhe em cada critério, A lista de verificação está agrupada por princípio do WCAG: Percetível, Operável, Compreensível, Robusto. Trabalhe em cada secção sistematicamente.
- 2Teste cada item antes de o marcar, Não marque itens como Passa com base em suposições. Utilize as orientações de teste fornecidas para cada critério.
- 3Utilize N/A quando os critérios genuinamente não se aplicam, Por exemplo, se o seu produto não tiver conteúdo de vídeo, marque os critérios de legendas como N/A.
- 4Registe evidências para os Passa, Indique como testou cada Passa: ferramenta automatizada, teste de teclado, teste com leitor de ecrã ou inspeção visual.
- 5Exporte a sua lista de verificação concluída, Transfira a lista de verificação como documento Word para o seu Ficheiro Técnico.
Está a utilizar a versão gratuita. O Gerador de Grelha de Auditoria Pro acrescenta:
- ✓ Exportação CSV com nome do projeto e do auditor
- ✓ Mapeamento regulatório EAA (EN 301 549)
- ✓ Mapeamento ADA / Section 508
- ✓ Estado «Pendente» para critérios em curso
- ✓ Referência de cláusula EN 301 549 por critério
- ✓ Resumos de critério em linha
Progresso guardado apenas neste navegador, Iniciar sessão Para guardar entre dispositivos
0 / 59 avaliados
0% concluído
Prerecorded audio (e.g., a podcast clip) needs a transcript. Prerecorded video with no audio (e.g., a silent product demo) needs either a transcript or an audio track.
All prerecorded video that contains audio must have captions. Captions must be synchronised with the audio and include all speech and important non-speech sounds.
Prerecorded video with audio track must have either an audio description (narration of visual information) or a full text alternative describing what is shown.
Live video streams (webinars, live events, broadcasts) must have live captions provided in real time.
At Level AA, audio description (not just a text alternative) is required for all prerecorded video. The full audio description track must be provided.
Visual structure (headings, lists, tables, form groupings) must be conveyed in the code, not just through styling.
When the order of content matters for understanding, the DOM order must reflect the correct reading sequence — not just the visual layout.
Instructions must not rely exclusively on visual cues like shape, color, or position. Include text-based references alongside sensory ones.
Websites and apps must not lock to portrait or landscape. Users with mounted devices (e.g., wheelchair-mounted tablets) may be unable to rotate.
Form fields collecting personal data must have autocomplete attributes so browsers and assistive technologies can autofill them.
Never use color as the only way to communicate something. Always provide a secondary non-color cue.
Audio that auto-plays for more than 3 seconds must be pausable or have independent volume control.
Normal text needs 4.5:1 contrast ratio against its background. Large text (18pt/24px or 14pt/~19px bold) needs 3:1.
Users must be able to zoom to 200% without losing content or functionality.
Use real HTML text instead of images of text wherever technically possible. Images of text cannot be resized, reflowed, or read by screen readers without alt text.
At 320px viewport width (equivalent to 400% zoom on a 1280px screen), all content must be accessible without horizontal scrolling.
The visual boundaries of form fields, buttons, checkboxes, and graphical elements used to understand content must have 3:1 contrast against adjacent colors.
When users override text spacing (line height 1.5×, paragraph spacing 2×, letter spacing 0.12em, word spacing 0.16em), no content should be lost or obscured.
Tooltips and hover popups must be: hoverable (mouse can move over them), dismissible (Escape closes them), and persistent (they stay until explicitly closed).
Everything a mouse user can do, a keyboard user must also be able to do. No functionality should require a mouse.
Keyboard users must never get stuck. Focus must always be escapable. Intentional focus traps in modals are acceptable only if Escape closes the modal.
Single-character keyboard shortcuts (like 'G' to go, 'F' for find) must be disableable or remappable. They conflict with speech input users who dictate text.
Session timeouts, time-limited forms, and timed quizzes must give users a way to turn off, adjust, or extend the time limit.
Moving, blinking, or auto-updating content must have a pause/stop/hide control. This includes carousels, tickers, animated banners, and live feeds.
Content must not flash more than 3 times per second. Flashing content can cause seizures in people with photosensitive epilepsy.
Keyboard users must be able to skip past repeated navigation blocks to reach the main content quickly.
Every page must have a descriptive <title> element that helps users understand what the page is about.
The keyboard Tab order must follow a logical sequence — typically top-to-bottom, left-to-right in Western languages — that preserves meaning.
Link text must be descriptive enough to understand its destination — either from the text alone or from its surrounding context.
Users must have more than one way to find any page on the site (e.g., navigation + site search, or navigation + sitemap).
When headings and form labels are used, they must be descriptive — they need not be comprehensive, but they must accurately describe their associated content.
Keyboard users must always be able to see which element has focus. Never suppress the focus outline completely.
New in WCAG 2.2: sticky headers, cookie banners, and chat bubbles must not completely cover the focused element.
At AAA level: the focused element must be completely visible — not even partially obscured by sticky content.
Level AA (WCAG 2.2): the focus indicator must cover at least a 2 CSS pixel perimeter of the unfocused component and have 3:1 contrast between focused and unfocused states.
Any feature requiring a swipe, pinch, or multi-finger gesture must have an equivalent single-tap or click alternative.
Don't trigger actions on mousedown/touchstart if the user might accidentally tap. Use mouseup/click (which fires on up-event) so users can cancel by moving away.
The accessible name of a button or link must contain the visible text label — this is essential for voice control users who say what they see.
Features that use device shake, tilt, or motion must also be operable via standard UI controls, and motion must be disableable.
New in WCAG 2.2: drag-and-drop must have a click/tap alternative. Sliders must be adjustable without dragging.
New in WCAG 2.2: interactive targets must be at least 24×24 CSS pixels, OR have sufficient spacing between targets.
The <html> element must have a lang attribute set to the page's primary language.
When content switches language (e.g., a French quote in an English article), the language change must be marked with a lang attribute.
Receiving focus must never automatically navigate, submit a form, or launch a popup. Focus changes must be predictable.
Changing a form control (selecting a dropdown option, checking a box) must not automatically navigate or submit without warning.
Navigation menus must appear in the same order on every page. Users with cognitive disabilities rely on consistent placement.
The same function must have the same label everywhere on the site. A search button should not be labelled 'Search' on one page and 'Find' on another.
New in WCAG 2.2: help mechanisms (phone number, live chat, FAQ link) must appear in the same relative position on every page where they appear.
When a form error is detected automatically, the specific field in error must be identified and described in text.
Every form input must have a visible label. Instructions about required format (date format, password rules) must be provided before the input.
Error messages must tell users how to fix the error — not just that an error occurred. Exceptions apply for security-sensitive validations.
High-stakes forms (purchases, legal agreements, exam submissions, data deletion) must let users review, correct, or reverse the action.
New in WCAG 2.2: if users must re-enter data they already provided in the same session, auto-populate it or let them select it from a list.
New in WCAG 2.2: authentication must not require a cognitive-only challenge unless an alternative exists. Password managers and magic links must be supported.
New in WCAG 2.2 (AAA): No authentication step may require a cognitive function test of any kind. Unlike SC 3.3.8, there are no exceptions for object recognition or personal content — all authentication must be cognitive-test-free.
SC 4.1.1 is obsolete in WCAG 2.2 and always passes with modern browsers. It was removed because modern browsers handle malformed HTML gracefully and assistive technologies do not rely on valid HTML parsing.
Every interactive element must expose its name (what it is called), role (what type of control it is), and current state/value to assistive technologies.
Success messages, loading states, result counts, and errors must be announced by screen readers without moving focus to them.
Sobre esta grelha
Esta grelha interativa cobre todos os 59 critérios de sucesso WCAG 2.2. O progresso é guardado automaticamente no seu navegador e, quando tem sessão iniciada, na nuvem. Utilize os botões de exportação para transferir um ficheiro CSV que abre diretamente no Microsoft Excel ou no Google Sheets.
Recomendação Oficial WCAG 2.2 do W3CEnviar esta lista a um fornecedor
Descarregue um documento Word em branco ou abra uma vista para impressão para enviar a lista completa de auditoria WCAG 2.2 a um terceiro (fornecedor, agência, auditor externo) para preenchimento. A versão em branco apresenta cada critério de sucesso agrupado por princípio POUR com caixas vazias Conforme / Reprovado / N/D e uma coluna de Notas.
Exportar como prova
0/59 assessed · 0 pass · 0 fail · 0 N/A
Cada exportação inclui um rodapé de metadados de prova legal com o ID da auditoria, data de geração, versão da ferramenta, cláusulas EN 301 549 e o aviso padrão. Prova de grau legal, não aconselhamento jurídico.
Aviso jurídico importante
Esta ferramenta é apenas um auxílio de autoavaliação e não constitui aconselhamento jurídico nem uma avaliação de conformidade formalmente certificada. As saídas, incluindo relatórios, pontuações, listas de verificação e declarações de acessibilidade, destinam-se a uso interno e devem ser revistas por um representante jurídico qualificado ou por um auditor de acessibilidade independente antes de serem utilizadas para fins regulamentares, de aquisição ou de divulgação pública. Todo o risco da avaliação recai sobre o avaliador interno. A accessibilityref, os seus criadores e equipa não aceitam qualquer responsabilidade por perdas decorrentes da utilização ou confiança nestas saídas. Verifique sempre junto das fontes oficiais: a Recomendação W3C WCAG 2.2, o European Accessibility Act (Diretiva 2019/882), e a autoridade de fiscalização nacional aplicável.
Pronto para fazer uma auditoria a sério?
Atualize para Pro para exportar os seus resultados em CSV, mapear conclusões para os regulamentos EAA e ADA e adicionar dados do projeto e do auditor para entrega profissional.