The Web Content Accessibility Guidelines (WCAG) are the internationally recognized standard for making digital content usable by people with disabilities. Published by the World Wide Web Consortium (W3C), WCAG is organized around four principles — Perceivable, Operable, Understandable, and Robust (the POUR principles) — which break down into guidelines, and then into testable success criteria. Those criteria are grouped into three conformance levels: A (minimum), AA (the level most commonly required by law and policy), and AAA (the most demanding).
In this course, WCAG gives you a shared, checkable vocabulary for talking about interface quality. Instead of saying a design "feels hard to use," you can point to a specific success criterion — contrast, keyboard access, focus visibility, target size — and explain exactly what must change. This matters practically as well: WCAG 2.0, 2.1, and 2.2 AA are referenced by accessibility laws and procurement requirements in many countries, so knowing the structure and versions is part of professional competence.
As you watch the videos below, focus on three things: how a success criterion is worded and why that wording makes it testable, how the version numbers (2.0, 2.1, 2.2) build on one another rather than replacing one another, and how individual criteria map back to the POUR principles. Keep a running list of criteria you could actually check on an interface you have built — you will need that skill for the module assignments.
A plain-English overview of what WCAG is, who publishes it, and how the guidelines are structured into principles, guidelines, and success criteria. Based on its title and description, it should walk through the role of WCAG as the technical standard behind accessibility requirements and explain the conformance levels A, AA, and AAA. Expect general orientation rather than deep code-level implementation detail.
This is the natural starting point for the topic: it covers the "what WCAG is and why it matters" and "conformance levels" subtopics in one accessible explanation, from a channel focused specifically on accessibility and ADA compliance.
A short comparison of WCAG versions 2.0, 2.1, and 2.2 at the AA level, explaining how the newer versions relate to the older ones. It should clarify that later versions are additive — existing criteria carry forward while new ones are introduced — which is a common point of confusion for students and practitioners.
Four minutes of version clarity prevents a lot of later confusion, especially since course outcomes and many legal requirements reference WCAG 2.1 AA specifically while 2.2 is now current.
A summary of the six success criteria added at the AA level in WCAG 2.2, including items such as Focus Not Obscured (Minimum). The chaptered description suggests each criterion is introduced in turn with an explanation of what it requires. This gives you concrete examples of how a success criterion is written and what it asks a designer to verify.
It moves from structure to application, showing what individual success criteria actually look like and how they address real interaction barriers — directly supporting the "applying WCAG success criteria" subtopic.
Together these videos build the standards literacy MO1 requires: the overview establishes WCAG's structure and conformance levels, the version comparison situates WCAG 2.1 among its neighbors, and the 2.2 summary demonstrates concrete, testable criteria. The specific criteria discussed — focus visibility, target size, and related requirements — give you a checklist mindset for detecting visual, motor, and cognitive barriers in an existing interface (MO2) and for revising prototypes to meet a defined conformance level (MO3). Because WCAG AA is the benchmark cited in accessibility law and policy, understanding it also grounds the ethical and legal reasoning called for in MO4.
These videos were chosen from YouTube on October 3, 2026. Each has captions; the player turns them on. Videos on YouTube can be changed or removed — if one no longer plays, tell your instructor. If a player does not appear, use its Watch on YouTube link.
Visual design decisions that feel purely aesthetic — a brand color, a light gray caption, a thin typeface, a removed focus outline — can quietly make an interface unusable for people with low vision, color vision deficiency, or age-related sight changes. This topic looks at the visual layer of accessibility: how much contrast text and UI components need, why color alone cannot carry meaning, how typography choices affect readability, and how users who navigate by keyboard need to see where they are on the page.
These concerns are codified in the WCAG 2.1 success criteria you are studying in this module, most notably the contrast ratio thresholds for text and non-text content, the "use of color" criterion, and the requirements for visible focus. Knowing the numbers matters, but so does knowing how to measure them with real tools and how to fix a design without throwing away its visual identity.
As you watch, pay attention to three things: the specific ratio targets and what counts as large text, the workflow each presenter uses to test an existing screen, and the design moves they make when a color fails — adjusting lightness, adding an icon or text label, or changing the element rather than the palette. Try the same steps on an interface you use daily, or on your own prototype.
A short, practical walkthrough of checking color contrast against WCAG 2.1 AA requirements using common tools such as the TPGI Colour Contrast Analyser and the WebAIM contrast checker. Expect to see colors sampled from a real interface, ratios reported, and pass/fail results interpreted against the standard.
It is the most direct, hands-on treatment of the contrast ratio subtopic, and The Accessibility Guy frames everything explicitly in terms of WCAG criteria, which connects the measurement step to the standards you need to cite.
A designer-oriented look at contrast failures and how to repair them, covering what the requirements actually ask for and how to adjust colors so a palette still works visually while passing. Given the channel's focus on type, expect discussion of text legibility, size and weight alongside the color values themselves, plus an accompanying cheat sheet.
Pimp my Type bridges the contrast and typography subtopics, showing not just that a color fails but how to fix it — which supports the prototype-revision work in this module.
A beginner-friendly tutorial that builds accessible UI choices into a Figma design workflow, discussing why accessible interfaces matter and demonstrating several techniques for achieving them. Likely topics include color and contrast checks, legible text sizing, and designing states and indicators so meaning does not depend on color alone.
It places accessibility inside a design tool students are likely to use for prototypes, making it a good complement to the testing-focused videos and a natural lead-in to avoiding color as the sole indicator and designing visible visual states.
Together these videos move from standard to inspection to repair. The TPGI/WebAIM walkthrough grounds you in WCAG 2.1 AA contrast criteria and the tools that verify them (MO1), and both testing-oriented videos model how to audit an existing screen for visual barriers such as low-contrast text or invisible focus states (MO2). The Pimp my Type and Figma tutorials then show how to change a design — colors, type, labels, indicators — so it meets those thresholds without losing its character (MO3). The recurring argument in all three, that these are requirements rather than preferences because real users are excluded when they are ignored, supports the ethical and legal reflection asked for in MO4.
These videos were chosen from YouTube on October 3, 2026. Each has captions; the player turns them on. Videos on YouTube can be changed or removed — if one no longer plays, tell your instructor. If a player does not appear, use its Watch on YouTube link.
Screen readers turn an interface into speech or braille, but they can only convey what the underlying code actually communicates. A heading that is merely large, bold text is just text to a screen reader; a heading marked up as a heading becomes a navigable structure a user can jump through. This topic looks at the layer beneath the visual design — semantic HTML elements, landmark roles, ARIA labels and descriptions, text alternatives for images and media, and announcements for content that changes after page load.
This matters in CEN3722 because interface design is not finished when it looks right. A prototype that passes a visual review can still be unusable for someone who is blind or has low vision if its structure is invisible to assistive technology. Learning to think in terms of roles, names, states, and reading order gives you a vocabulary for evaluating and repairing interfaces, and connects directly to WCAG success criteria you will apply later in the module.
The three videos below come from the same accessibility instructor and are best watched in order. As you watch, pay attention to one recurring theme: ARIA supplements semantic HTML, it does not replace it. Note which native HTML elements already carry accessibility information for free, when an ARIA attribute is genuinely needed, and how incorrect ARIA can make an interface worse than no ARIA at all. Keep a running list of the specific elements and attributes mentioned so you can check for them in your own prototypes.
An updated introduction to semantic HTML, explaining how choosing elements for their meaning rather than their appearance reinforces the structure of page content. Based on its description, it covers the difference between elements that convey meaning and those that only affect presentation, and why that distinction matters for assistive technology. Expect examples of common semantic elements and headings used to build a navigable document structure.
It directly supports the Semantic HTML subtopic and establishes the foundation the other two videos build on, from an instructor who specializes in accessibility teaching.
This video focuses on ARIA landmarks — the attributes and roles that mark out regions of a page such as navigation, main content, and complementary areas. It introduces WAI-ARIA as a set of attributes added to HTML and explains the role landmarks play in letting screen reader users move quickly between major sections. Expect discussion of which landmarks exist and how they map onto page regions.
It covers the Landmark Roles subtopic specifically, showing how structural navigation works in practice rather than treating accessibility as a checklist item.
A broader explanation of what WAI-ARIA is and how it relates to native HTML. The description makes clear the central point: ARIA only helps when used correctly and can never replace semantic HTML, so the video addresses why and when ARIA is appropriate. This is the natural place to encounter ARIA attributes used for naming and describing elements.
It frames the ARIA Labels and Descriptions subtopic with the correct caution about misuse, which is essential before students start adding ARIA to their own prototypes.
Together these videos give students the technical grounding needed to recognize WCAG-related requirements around structure, name, role, and value (MO1) and to inspect an existing interface for barriers that affect users of screen readers (MO2). The emphasis on correct semantic markup and the appropriate, limited use of ARIA gives students concrete changes they can make when revising interface prototypes for accessibility (MO3). By showing how much of a page's meaning is invisible unless it is coded deliberately, the videos also make tangible the consequences of exclusion for blind and low-vision users, supporting reflection on the ethical and legal responsibilities of designers (MO4). Note that the videos concentrate on semantics, landmarks, and ARIA; you should supplement them with course readings on image and media alternatives and on live regions for dynamic content.
These videos were chosen from YouTube on October 3, 2026. Each has captions; the player turns them on. Videos on YouTube can be changed or removed — if one no longer plays, tell your instructor. If a player does not appear, use its Watch on YouTube link.
Meeting WCAG success criteria is a floor, not a ceiling. Inclusive design asks a broader question: who is being left out by the choices we make, and how can an interface flex to accommodate the full range of human abilities, contexts, and preferences? This topic introduces the social model of disability — the idea that people are disabled by barriers in the environment rather than by their bodies or minds — and the design mindset that follows from it.
Four threads run through the material. The social model and inclusive mindset reframe accessibility as a design responsibility rather than a compliance checkbox. Cognitive accessibility focuses on memory load, attention, clear language, predictable structure, and giving users enough time. Responsive and adaptive design extends accessibility across screen sizes, zoom levels, input methods, and user settings. Animation and motion sensitivity cover the real harm that movement, auto-advancing content, and parallax effects can cause for users with vestibular disorders, migraine, or attention differences.
The three videos below come from the Web Accessibility For All series. As you watch, look for the pattern each one follows: a common design pattern is named, the specific users it excludes are identified, and a more inclusive alternative is proposed. Try to connect each example back to a WCAG criterion you already know, then notice where the recommendation goes beyond what the standard literally requires — that gap is where inclusive design lives.
PLACEHOLDER
These videos were chosen from YouTube on October 3, 2026. Each has captions; the player turns them on. Videos on YouTube can be changed or removed — if one no longer plays, tell your instructor. If a player does not appear, use its Watch on YouTube link.
An accessibility audit is a systematic evaluation of an interface against a standard — usually WCAG 2.1 — to find, document, and prioritize barriers that keep people with disabilities from using a product. Auditing sits between knowing the guidelines and actually fixing things: it is the activity that turns an abstract success criterion like "non-text content has a text alternative" into a concrete, located, reproducible defect that someone on a team can repair.
In this course, auditing matters because it is how you check your own work. Automated checkers can flag perhaps a third of common issues, so a usable audit method combines tooling (browser extensions, DevTools panels, contrast checkers) with manual inspection (keyboard-only navigation, heading and landmark structure, focus order, form labels, meaningful alt text) and, where possible, testing with assistive technology. You will apply this to your own prototype, then decide what to fix first and how to write it up.
As you watch, pay attention to three things: the method each presenter uses to select pages and work through them in a repeatable order; the evidence they capture for each finding (location, standard violated, what the user experiences, suggested remediation); and the judgment calls about severity — which failures block a task entirely versus which degrade the experience. Notice also how the tools differ in purpose: WAVE surfaces page structure and flags for human review, DevTools digs into the accessibility tree and computed properties, and a formal audit report packages all of it for stakeholders.
Pope Tech demonstrates using the WAVE browser extension together with a small sample of pages as the launching point for a manual accessibility audit. Expect coverage of how to read WAVE's errors, alerts, contrast flags, and structure panels, and how automated flags are used as prompts for human verification rather than as a finished result.
Pope Tech is an accessibility tooling vendor with deep WAVE expertise, and the video directly models the audit-methods and page-sampling workflow you will reuse when auditing your own prototype.
Kris Rivenburgh of The ADA Book explains, at a conceptual level, what a digital accessibility audit is and how one is typically conducted for websites, apps, and other digital assets. The video is likely to cover the scope of an audit, how it relates to WCAG conformance and legal compliance expectations, and what a client or team should expect to receive as output.
It is the right starting point because it frames audits as a process and a deliverable rather than a tool, which sets up the subtopics on prioritizing findings and writing them up for an audience.
This Chrome for Developers session walks through the accessibility features built into Chrome DevTools, including inspecting the accessibility tree, reviewing computed accessible names and roles, contrast checks, and automated auditing panels. It is aimed at developers debugging specific accessibility defects in a live page.
It complements WAVE by showing how to diagnose why an element fails — essential evidence when you need to write a finding that a developer can act on — and it comes directly from the browser team that builds the tooling.
Together these videos move from definition to practice: the ADA Book overview connects auditing to WCAG and to the legal and ethical obligations behind accessible design (MO1, MO4), while the WAVE and Chrome DevTools demonstrations give you concrete techniques for inspecting a live interface and detecting barriers affecting visual, motor, and cognitive access (MO2). Because both tool videos surface not just the existence of a problem but its cause in markup and structure, they feed directly into revising your own prototype to meet standards and into writing findings that specify an actionable remediation (MO3).
These videos were chosen from YouTube on October 3, 2026. Each has captions; the player turns them on. Videos on YouTube can be changed or removed — if one no longer plays, tell your instructor. If a player does not appear, use its Watch on YouTube link.
Finding accessibility problems is only half the work. This topic is about the other half: turning audit findings into concrete design corrections and then standardizing those corrections as reusable patterns. Instead of fixing one broken form or one trapped modal at a time, you build a small library of components — form fields, navigation, dialogs, tables and charts — that are accessible by default, so the same defect does not reappear on the next screen.
The subtopics move through the component types that generate the most accessibility complaints. Forms need programmatic labels, grouping, and error messaging that assistive technology can announce. Navigation needs predictable structure, skip links, and keyboard reachability. Modals and overlays need focus management, correct roles, and a reliable way to dismiss them. Data displays — tables and charts — need structure and text alternatives so information is not locked inside visual layout alone. Finally, these fixes need a home in your design workflow so accessibility is checked each iteration rather than bolted on at the end.
The three videos below are short, hands-on walkthroughs of three of these component families. While watching, pay attention to the distinction between what is visible and what is programmatically exposed: a label you can see is not the same as a label a screen reader can read. Note also which techniques rely on native HTML semantics and which require ARIA plus JavaScript, and keep track of the keyboard behavior being demonstrated so you can reuse it as a checklist when you revise your own prototypes.
A step-by-step walkthrough of making HTML form elements accessible, covering the markup and attribute choices that connect visible labels, inputs, and supporting text so assistive technology can interpret them. Based on its title and framing as part of a web accessibility series, expect coverage of labeling techniques, form structure, and common markup mistakes that break screen reader output. At roughly sixteen minutes, it is a practical code-level treatment rather than a conceptual overview.
Forms are the single most common source of accessibility defects in student prototypes, and this video maps directly to the Designing Accessible Form Components subtopic with concrete, reusable markup patterns you can carry into your own component library.
Revisit this modal walkthrough when you reach the iteration subtopic, since dialog behavior is one of the easiest things to regress as a design changes. Pay particular attention to the sequence of focus moves demonstrated, which you can convert into a repeatable manual test step.
Using the same demonstration as a test script supports the Iterating on Accessibility in Design Workflows subtopic by turning a one-time fix into a recurring check.
A short, focused look at making data tables accessible, likely covering table structure elements such as headers, captions, and the relationships that let a screen reader announce which cell belongs to which row and column. The compact runtime suggests a tight demonstration of the core markup rather than an exhaustive treatment of complex table cases.
Tabular data is the foundation of the Accessible Data Visualization subtopic — before charts can be made accessible, the underlying data structure must be readable — and this video shows the semantic pattern you can reuse wherever data is displayed.
Together these videos move the module from recognition to repair. They put WCAG-aligned techniques for labeling, focus management, and data structure into practice (MO1) and show the specific barriers — unlabeled inputs, lost keyboard focus, structurally meaningless tables — that an audit of visual, motor, and cognitive access would surface (MO2). Most directly, each is a demonstration of modifying markup and behavior so a prototype meets accessibility standards, which is the core of applying inclusive design principles to real components (MO3). Seeing how small implementation choices determine whether a user can complete a form or escape a dialog also makes the human cost of exclusion concrete, supporting your ability to articulate the ethical and legal stakes of these decisions (MO4).
These videos were chosen from YouTube on October 3, 2026. Each has captions; the player turns them on. Videos on YouTube can be changed or removed — if one no longer plays, tell your instructor. If a player does not appear, use its Watch on YouTube link.