Glossary

What Is Web Accessibility (WCAG)?

Web accessibility (often abbreviated a11y) is the practice of designing and building websites that can be used by everyone, including people with visual, auditory, motor, or cognitive disabilities. The Web Content Accessibility Guidelines (WCAG), maintained by the W3C, provide the international standard for web accessibility. WCAG 2.1 AA is the most widely required compliance level for public-facing websites.

The four WCAG principles (POUR)

Perceivable, all information must be presentable in ways users can perceive (alt text on images, captions on videos, sufficient colour contrast). Operable, all interface components must be operable (keyboard navigation, no seizure-inducing content, enough time to interact). Understandable, content and UI must be understandable (clear language, consistent navigation, helpful error messages). Robust, content must be interpreted reliably by assistive technologies (valid HTML, ARIA attributes used correctly).

How WCAG works

WCAG defines success criteria, each mapped to a conformance level. Level A covers the most critical barriers (such as providing text alternatives for images via the alt attribute). Level AA, the target for most legal compliance frameworks including the ADA, Section 508, and the EU Web Accessibility Directive, adds requirements like sufficient color contrast ratios (4.5:1 for normal text), visible keyboard focus indicators, and captions for live audio content. Developers test against these criteria using a combination of automated tools (Axe, Lighthouse, WAVE) and manual audits with real assistive technologies like NVDA, JAWS, or VoiceOver. Technically, WCAG compliance depends heavily on correct use of HTML semantics and ARIA (Accessible Rich Internet Applications) attributes. Semantic HTML elements like nav, main, header, and article provide document structure that screen readers expose through their accessibility tree. When native HTML semantics are insufficient, for example for a custom dropdown built from div elements, ARIA roles and properties like role='combobox', aria-expanded, and aria-controls supply the missing context. The rule is to use native HTML first and ARIA only as a supplement, since misapplied ARIA often creates more barriers than it removes. Keyboard accessibility is one of the most technically demanding WCAG requirements. Success criterion 2.1.1 requires all functionality to be operable via keyboard alone. This means managing focus order logically through the DOM, using tabindex='0' to make custom interactive elements focusable, and implementing keyboard event handlers (keydown, keyup) alongside click handlers. Modal dialogs require focus trapping so keyboard users cannot tab outside the active layer, and all modals must return focus to the triggering element on close. Color contrast is another measurable, technical criterion. WCAG 2.1 SC 1.4.3 requires a contrast ratio of at least 4.5:1 between foreground text and its background for normal text and 3:1 for large text (18pt or 14pt bold). This ratio is calculated using the relative luminance formula defined in the WCAG specification itself. Developers can validate contrast using browser DevTools color pickers, the WebAIM Contrast Checker, or design tools like Figma with accessibility plugins. Gradients and background images behind text require special care since contrast must be verified across the entire text rendering area.

Key accessibility requirements

Colour contrast: normal text must meet 4.5:1 contrast ratio (AA level). Large text (18pt+ or 14pt bold) needs 3:1. Alt text: all images need descriptive alt attributes. Keyboard navigation: all interactive elements must be reachable and operable by keyboard. Focus indicators: focused elements must be visually distinct. Heading hierarchy: single H1, logical H2 to H6 structure. Form labels: every input must have an associated label element.

Web accessibility best practices

Always write descriptive, context-specific alt text for informational images rather than filename dumps or phrases like 'image of'; decorative images should use alt='' (empty string, not absent) so screen readers skip them entirely. Use a single h1 per page and maintain a logical heading hierarchy (h1 through h6) that mirrors document structure, because screen reader users frequently navigate pages by jumping between headings. Ensure every form input has a programmatically associated label using the for/id pairing or by wrapping the input inside the label element, never relying solely on placeholder text since placeholders disappear on focus and are not reliably announced. Test your focus styles by pressing Tab through every interactive element on the page and confirm a visible outline exists; do not simply write outline: none in your CSS without providing an equivalent replacement, and leverage the :focus-visible pseudo-class to show focus styles only for keyboard navigation without affecting mouse users.

Accessibility and SEO

Many accessibility practices directly benefit SEO: alt text helps Google understand images (and is used for image search ranking), semantic HTML helps crawlers parse page structure, fast performance benefits users with slow connections, and clear heading hierarchy helps both users and crawlers understand content organisation. Accessible sites typically rank better.

Web Accessibility (WCAG) and Canvas Builder

Canvas Builder generates HTML using Bootstrap 5, which includes built-in accessibility features, ARIA attributes on modals, dropdowns, and navigation, plus proper semantic structure for screen reader compatibility.

Start building free

Frequently asked questions

What WCAG level should I target?

WCAG 2.1 AA is the practical standard for most websites and the level required by many accessibility laws (ADA in the US, EN 301 549 in Europe, AODA in Canada). AAA is the highest level and is impractical for most general sites.

What is the difference between WCAG 2.1 and WCAG 2.2, and which should I target?

WCAG 2.2 was published in October 2023 and is fully backward-compatible with 2.1, meaning it adds nine new success criteria rather than replacing old ones. Notable additions include SC 2.4.11 (Focus Not Obscured), which ensures sticky headers do not completely cover the focused element, and SC 2.5.7 (Dragging Movements), requiring that any drag-and-drop functionality have a single-pointer alternative. Most legal frameworks currently reference WCAG 2.1 AA, but targeting 2.2 AA is the safer long-term approach since regulations will eventually catch up to the newer version.

Does using ARIA automatically make a component accessible?

No, ARIA only modifies how the accessibility tree exposes semantics to assistive technologies; it does not add keyboard behavior, manage focus, or prevent invalid states from being announced. For example, adding role='button' to a div makes a screen reader announce it as a button, but you must still manually add tabindex='0' to make it focusable and a keydown handler for Space and Enter keys to replicate native button behavior. The first rule of ARIA use is: if a native HTML element can do the job, use that instead, because native elements come with built-in keyboard support and semantics at no extra cost.

Does Canvas Builder generate accessible HTML?

Canvas Builder generates HTML with proper alt attributes on images, semantic structural elements, and Bootstrap 5's built-in accessibility features including ARIA roles on interactive components.