Web Accessibility: Fundamental Principles

This section presents the four POUR pillars of WCAG, followed by key recommendations at each level and links to detailed sections.

Perceivable: Transcripts, text alternatives, sufficient contrast, clear visual organisation.
Operable: Keyboard navigation, logical tab order, skip links, mobile compatibility.
Understandable: Declared language, consistent feedback, simple instructions, cognitive accessibility.
Robust: Compatibility with assistive technologies, ARIA compliant, code validation.

Accessibility Guides

Implement WCAG best practices, accessible SEO, Core Web Vitals, and access interactive tutorials to create inclusive web experiences.

Effective keyboard navigation is essential for accessibility. Follow these principles:

Visible Tabulation: Ensure a consistent focus order that follows the page's visual structure.
Logical Order (tabindex)
Intentionally exclude non-interactive elements by setting tabindex="-1" in the code.
Skip Links: Add skip links like <a href="#main-content">Skip to main content</a> at the beginning of the page.
Focus Visibility: Use :focus and :focus-visible styles with high contrast (minimum 3:1 against the background).
Mouse-Free Features: All buttons, menus, and forms must be usable with keyboard only.

Test with: Tab, Shift+Tab, Enter, Space, arrow keys.
Complete WebAIM Guide on Keyboard Navigation

Accessible forms improve the experience for all users:

Unambiguous Labels: Use <label for="id"> linked to each input field (and button) for explicit association.
Accessible Error Messages in real time: Add role="alert" or aria-live="polite" to notify screen reader users.
Instructions Before the Field: Place necessary indications before the input, not after.
Alternative CAPTCHA: Offer audio or mathematical alternatives to visual CAPTCHAs.
Logical Grouping: Use <fieldset> and <legend> to group related fields (dates, addresses).

Create understandable content for everyone, including those with cognitive difficulties:

Simple Language: Avoid technical jargon and unexplained abbreviations.
Clear Instructions: Use linear presentation and numbered steps.
Reduce Distractions: Respect prefers-reduced-motion to limit animations. Avoid animations that auto-start on page load.
Generous Spacing: Air out content to facilitate reading and concentration.
Immediate Feedback: Confirm user actions quickly and clearly.

Golden Rule: "No ARIA is better than bad ARIA" - Use ARIA to complement semantic HTML, never as a replacement.

aria-label: For buttons with icons without visible text (e.g., <button aria-label="Close"><i class="fa-times"></i></button>).
aria-expanded: To indicate the open/closed state of accordions and dropdown menus.
role="alert": For important notifications requiring immediate attention.
aria-live: For dynamic updates (values: "polite", "assertive", "off").
Do Not Overload: Limit ARIA use to cases where native HTML is insufficient.

Complete ARIA Cheat Sheet

Make all multimedia content accessible:

Large, spaced touch targets.
No elements trapped by absent hover/focus on mobile.
Zoom allowed, no fixed-viewport (user-scalable=yes).
Linear navigation
Mobile screen readers (VoiceOver, TalkBack)
Do not rely on overlays: Prioritise deep code correction. Consider an external expert audit or user panel.

Recommended tools: Tenon API, Axe Mobile, MDN Mobile Accessibility

Automatic overlays (widgets, toolbars) do not provide real WCAG compliance. Prioritise native code correction!
Reference: Why Avoid Overlays

Include disabled people in tests; various disabilities (visual, motor, auditory, cognitive, etc.).
Observations on real navigation.
Collect direct feedback via adapted questionnaires.
Test keyboard only, screen readers (NVDA, JAWS, VoiceOver), and touch navigation.
Combine automated audits (Axe, WAVE…) and manual corrections with real user feedback.

Practical Guide: WAI User Testing

Respect cultures, multilingual access, texts compatible with automatic translation.
Localised date, time and currency formats.
Test across multiple regions and languages.

See: W3C i18n Best Practices

Explore our selection of tools to test and improve the accessibility of your websites.

AccessScan produces WCAG 2.2 and ADA reports with AI-generated alt-text
Axe DevTools (Deque): integrated with VSCode, produces detailed reports
WAVE (WebAIM): visual scans and WCAG audits
pa11y: Open-source CLI tool for automated tests in CI/CD
Tenon API for scalable audits, with focus on mobile and AI.
Test on mobile (VoiceOver/TalkBack), contrast tools (WebAIM Contrast Checker), form analysers

Adopt the best practices for a more inclusive and performant web.

IAAP certification
Section 508
WCAG 2.2: Focus on operability: criteria 3.3.7 (Drag-and-Drop: all drag-and-drop functionality must be achievable without drag, unless essential) and 3.2.6 (Consistent Help: repeated help mechanisms must appear in the same relative order on pages)
Colour Contrast (WCAG 1.4.3): Ensure a minimum contrast ratio of 4.5:1 for normal text (3:1 for large text). Formula: (L1 + 0.05) / (L2 + 0.05), where L1/L2 are luminances (calculable via tools like WebAIM Contrast Checker). Example: Avoid light grey (#CCCCCC) on white (#FFFFFF) – ratio 1.3:1, fails AA.
Use ARIA to enrich semantics without overloading (rule: "No ARIA is better than bad ARIA"). Examples: aria-label for buttons without visible text; role="alert" for dynamic notifications; aria-expanded for accordions.
Effective Alt-Text: Write concise and contextual descriptions. For decorative images, use alt="". For charts, describe key data.