Glossary

What Is Web Accessibility (WCAG)?

Web Accessibility (WCAG) refers to the Web Content Accessibility Guidelines published by the W3C, a set of technical specifications that define how web content should be structured and behaved so that people with disabilities, including those using screen readers, keyboard navigation, or assistive technology, can perceive, operate, and understand it. WCAG is organized around four principles (Perceivable, Operable, Understandable, Robust, abbreviated as POUR) and published in versioned conformance levels: A, AA, and AAA. WCAG 2.1 is the current baseline legal standard in most jurisdictions, while WCAG 2.2 introduced additional criteria focused on cognitive and motor accessibility.

What Is Web Accessibility (WCAG)?

How Web Accessibility (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.

Best Practices for Web Accessibility (WCAG)

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.

Web Accessibility (WCAG) & Canvas Builder

Canvas Builder produces HTML grounded in Bootstrap 5, a framework that treats accessibility as a first-class concern: its components use semantic elements (button, nav, label, figure), include appropriate ARIA attributes out of the box, and meet WCAG AA color contrast thresholds in its default color system. The clean, structured HTML output means developers receive a valid, well-ordered document tree rather than layers of presentational wrappers, which directly supports screen reader navigation and makes further accessibility customization straightforward. For teams building client sites that must meet legal accessibility standards, Canvas Builder's semantic foundation significantly reduces the remediation effort compared to starting with non-semantic generated markup.

Try Canvas Builder →

Frequently Asked Questions

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.

How does Canvas Builder support WCAG compliance in its generated HTML output?

Canvas Builder generates production-ready HTML using Bootstrap 5, which ships with accessibility baked into its component library: Bootstrap buttons are real button elements, form controls are paired with label elements by default, modals include aria-labelledby and focus management, and navigation components use the nav landmark and aria-current attributes. Because Canvas Builder outputs clean, semantic HTML rather than div-heavy generated code, the resulting pages have a logical DOM structure that screen readers and search engines can parse correctly from the start, reducing the manual accessibility remediation work that is common with visual drag-and-drop builders.