Lorenzo Cataldi
Design&Develop
WCAG 2.2
To obtain accessibility certification, I develop this toolkit inspired by Johannes Lehner's "Card Deck" project . Notice: this section is in English but it's also available in: Italiano
Listed Cards: 87.
All non-text content presented to the user must have an equivalent text alternative that serves the same purpose or provides descriptive identification.
Purely descriptive content, formatting, and invisible content must be hidden from assistive technologies (e.g., using an empty alt attribute or with the aria-hidden="true" attribute).
Prerecorded audio-only content must have a text transcript.
Prerecorded video-only content must have a text or audio description.
Prerecorded videos with audio must have synchronized captions that include: all speech and relevant sound effects (like music, alarms, or laughter).
Important visual content in prerecorded videos must be described using: an audio description or a text-based alternative.
Live video with audio must include real-time captions that include: speech and important sound effects (like music, alarms, or laughter).
Important visual content in prerecorded videos with audio must be described using an audio description, unless it is already explained in the main audio track.
All prerecorded videos with audio must include a sign language interpretation.
Prerecorded videos must include extended audio descriptions if important visual content like
can't be described during normal playback.
Prerecorded videos must have a full text alternative that includes
even if captions and audio descriptions are already available.
Live audio-only content must include a real-time text alternative, such as captions, or live transcripts.
Visual information and its relationships (such as labels, headings, groupings, etc.) must be made explicit in the code using
<label for="">, <ul>, <h1>, etc.) andaria-describedby="ID", etc.)so that assistive technologies can understand their structure.
Note: this criterion absorbs the deprecated 4.1.1.
The content must follow a logical and meaningful order in the code that respects the order of information perceived visually.
In this way, the visual layout can be correctly reproduced by assistive technologies.
Instructions and descriptions should not rely solely on sensory characteristics such as colour, shape, size, visual position or sound.
Always provide additional text to clarify the meaning. The description of an element, such as a button, cannot be limited to colour alone, for example.
Content must remain readable and usable in both portrait and landscape orientation, unless a specific one is essential (e.g. in a piano app that requires landscape to show the full keyboard).
The purpose of common form fields (such as name, telephone number, email address, address, etc.) must be defined in the code so that browsers and assistive technologies can offer support for data entry, such as autocomplete.
The purpose of regions and common elements must be defined in the code using semantic HTML elements (e.g. nav, aside, p, etc.) and ARIA attributes where necessary, so that:
Color must not be the only way to convey information.
Always provide an additional visual cue, like icon, text label, underline, shape, or pattern (e.g. striped, solid).
If audio is played automatically for more than 3 seconds, it must be possible to
regardless of the overall volume level of the system (for example, in order to avoid interrupting a screen reader).
The contrast between the text and the background must have at least the following ratios:
24px, or in bold and over 19px).Text remains readable and usable when zoomed to 200%.
Text must be actual text, not images of text, unless a specific visual presentation is absolutely necessary (e.g. logo).
Text contrast against its background must be at least
24px, or bold and over 19px).For pre-recorded audio with speech, any background sound must be
Blocks of text (like paragraphs) must
Allow users to adjust spacing and colors using custom styles.
Text must be actual text, not images of text (no exception, not even for design or aesthetic reasons).
The content remains functional and easy to read – the flow of text lines is correctly recalculated based on the width of the display window – when:
320px,without the need to scroll in two directions (except tables, maps and similar content).
Interactive controls (e.g. buttons, form fields, focus indicators) and graphics that convey meaning (e.g. icons, charts, graph lines) must have a contrast ratio of at least 3:1 against adjacent colors.
Text remains readable and usable when spacing is changed using custom styles to at least
without content being hidden, cut off, or broken.
When additional content appears on hover or keyboard focus (including long press on touch), it must
stay visible until dismissed or no longer valid, be dismissible (e.g. using the esc key), and remain visible when hovered or focused.
All functionality must be operable using a keyboard alone, unless the task requires freehand input (e.g. drawing).
It must always be possible to move the focus inside and outside any component using only the keyboard (e.g. tab, shift+tab, enter, esc), without getting stuck.
All functionality must be operable using a keyboard alone (no exception, not even for tasks involving gestures like drag-and-drop or pointer-based interaction).
Keyboard shortcuts must use modifier keys such as ctrl, cmd or alt/option. If single-key shortcuts are used (e.g. S to save), it must be possible to
Time limits must be avoided unless essential for the task (e.g. exams, auctions). If time limits are used, it must be possible to
If content moves, scrolls, blinks, or updates automatically for more than 5 seconds, it must be possible to
Content must not include time limits for reading or interaction, unless it's part of a live event or time-based activity (e.g. auctions, broadcasts).
Interruptions (like pop-ups, alerts, or notifications) must be able to be
except in emergencies (e.g. critical system warnings).
When re-authentication is required (e.g. after session timeout), all previously entered data must be preserved so the task can continue without starting over.
If inactivity could lead to data loss, a clear warning must be shown
Content must not flash, blink, or flicker more than three times per second, unless it stays within safety limits designed to avoid visual overload and reduce the risk of seizures.
Content must not flash, blink, or flicker more than three times per second (no exception, not even if it meets safety thresholds).
Animations triggered by interaction (e.g. on click, hover, tap) must be possible to
It must be possible to skip repeated blocks of content (e.g. navigation, header) and jump directly to the main part of the page.
Each page must have a unique and descriptive <title> that reflects its topic or purpose.
Focus must follow a logical and meaningful order that preserves relationships and matches how the page is naturally read, regardless of layout or language direction.
The purpose of each link must be clear from
Except in cases where the purpose of the link may be ambiguous to users in general.
At least two different ways must be available to find pages or content (e.g. navigation menus, on-page links, site search, or a sitemap).
Headings must describe what follows.
Labels and buttons must clearly communicate what information is needed or what action will happen.
A visible indicator must show which element is currently focused when navigating with a keyboard.
It must be clear where you are within a set of pages (e.g. using breadcrumbs, highlighted menu items, or headings).
The purpose of each link must be clear
Related content must be organized into clear sections using headings.
When an element receives focus, it must be at least partially visible.
Note: Given the complex responsive designs that are very common today, this AA criterion allows the component receiving focus to be partially obscured by other content created by the author.
When an element receives focus, it must be fully visible and not covered by other content.
The visible focus indicator must
Actions based on gestures (such as swiping or pinching) must also be possible with a single tap, click, or button.
Unless it is necessary for the user to interact with the service using gestures based on a specific path, e.g. through multiple points.
Actions must not trigger on press or touch down. They must only trigger on release (like mouse-up or finger lift).
The visible text of a button, link, or form field must also be part of its accessible (programmatic) name.
For example: the label of a link (a) may have, in addition to visible text, a non-accessible icon suggesting that the link will open in a new window.
The accessible name of the link must begin with the same text as the visible label and continue with "open in a new window".
If an action can be activated by movement (such as shaking or tilting the device), it must also
Targets for touch or mouse must be at least
It must be possible to switch between input types (mouse, keyboard, touch, voice) without losing access to any functionality.
Actions that require dragging (like reordering) must also be possible using buttons or another method that does not require dragging.
Targets must be at least 24×24px, unless they are
Each page must have a <html lang=""> attribute that matches the main language of the page.
Any parts of the content in a different language must be marked with the correct lang attribute.
Expressions borrowed from another language (like "déjà vu" in English) do not need this, unless pronunciation or understanding would be affected.
Unusual terms, jargon, or figurative language should be
Abbreviations and acronyms should be
If content requires reading skills above lower secondary education (around 9th grade), provide
to help with understanding.
If a word can be pronounced in different ways with different meanings, the intended meaning must be clarified to avoid confusion or ambiguity.
No unexpected changes must happen when an element receives focus (like open a popup, move focus, submit a form).
No unexpected changes in the context must happen when a field value changes (like auto-submit, reload, open new page).
Navigation elements (like menus, links, search) must appear in the same place and order across pages.
Navigation elements (like menus, links, search) must appear in the same place and order across pages.
Important changes (such as opening a dialogue box, navigating, sending a form) should only occur when expressly requested.
Help options (like contact link, support widget) must appear in the same place across pages.
Errors and validation must be clearly identified and described in text, not just visually (like color or highlighting).
Form fields must have clear labels or instructions to avoid confusion and help complete the input correctly.
Errors and validation messages must show text that
Before sending important actions (such as payments or data with legal value), the form must allow
Provide additional help (like text instructions, help links, or tooltips) when label alone might be ambiguous or confusing.
Before submitting, all forms must allow you to
Don't ask for the same information twice in the same process.
Provide pre-filled fields or selection options if the information was already given.
Authentication must not rely on memory alone.
Allow copy-paste, password managers, or other options (like email verification).
Authentication must not rely on memory or recognition (like solving puzzles, remembering images, or using CAPTCHAs).
This used to require HTML with proper structure and no critical markup errors (like missing tags or duplicate IDs).
The requirement is removed but still helps with compatibility.
Interactive elements must have
so that assistive technologies can interpret and interact with them correctly.
Status updates (like "form sent" or "5 items in cart") must
role="status" or role="alert"),