Loading
Every factual claim in this course traces to something here, grouped by the module it serves. Where a source is a vendor describing its own product or a consultant selling expertise in the subject, the note says so — not to discount it, but because a course about citing things correctly should be legible about who is speaking.
The normative documents, their informative companions, and the two regulations that name a version.
WhyThe normative document. Section 5 carries the five conformance requirements — Conformance Level, Full pages, Complete processes, Only Accessibility-Supported Ways of Using Technologies, and Non-Interference. This is the version the DOJ Title II rule names, so it is the version most conformance notes should target unless there is a reason to go further. Also cited in the four-patterns and focus-in-an-overlay lessons for the normative text of 2.1.1 Keyboard, 2.1.2 No Keyboard Trap, and 4.1.2 Name, Role, Value — the two Level A criteria a role without behaviour fails together, and the criterion that ends the argument about trapping focus in a modal.
WhyThe current Recommendation. Adds nine success criteria and removes 4.1.1 Parsing. States its own backwards compatibility: content conforming to 2.2 also conforms to 2.0 and 2.1. Source of the verbatim text for 2.4.11 Focus Not Obscured (Minimum).
WhyPrimary source for the conformance lesson. Where the Full pages and Complete processes requirements are stated in plain terms, where the two conditions of “accessibility supported” are defined, and where the Working Group explicitly declines to say which or how many assistive technologies must support a technology — deferring instead to “the community and to entities closer to each situation.” Also the source of the two sentences worth memorising: that no conformance claim is required in order to conform, and that content may satisfy all success criteria and still not always be usable by people with a wide variety of disabilities.
WhyThe authoritative list of the nine additions with their levels, and the statement that 4.1.1 Parsing is obsolete and removed. The page to check before quoting a 2.2 criterion’s level — 2.4.13 Focus Appearance is AAA, which is the error this course keeps flagging.
WhyNames WCAG 2.1 Level AA as the technical standard for state and local government web content and mobile apps, with compliance dates of 26 April 2027 for entities serving populations of 50,000 or more and 26 April 2028 for smaller entities and special district governments. Half of the reason “we are WCAG compliant” names nothing.
WhyThe Revised Section 508 Standards, effective 18 January 2017, incorporate “Level A and Level AA Success Criteria and Conformance Requirements in WCAG 2.0.” The other half: the federal procurement bar is still 2.0, which is a different set of criteria from the Title II bar and a different set again from the current Recommendation.
WhyPrimary source for the criteria lesson. The criterion most component authors have never read in full: it covers the visual information required to identify components and their states at 3:1, explicitly including focused and selected, while declining to require that controls have a visible boundary at all. The worked examples are what let you adjudicate a design review on this without hedging.
Why4.5:1, dropping to 3:1 for large-scale text at 18pt or 14pt bold — roughly 24px and 18.5px. Source of the disabled-control exemption, which is real and which is not a defence for an unreadable disabled state.
Why24×24 CSS pixels at Level AA, with five exceptions, of which Spacing is the one worth quoting exactly: a 24px-diameter circle centred on each undersized target’s bounding box must not intersect another target or another such circle. Read against 2.5.5 Target Size in WCAG 2.1, which is Level AAA at 44×44 — meaning a 2.1 AA target imposes no target-size obligation whatsoever.
WhyLevel AA. The definition of a status message — success or results of an action, waiting state, progress, or existence of errors — is what places extraction confidence, run progress and streamed output under this criterion rather than under 3.3.1. Contains the one piece of W3C guidance in this whole course that speaks directly to the streaming problem: “there is a risk of making an application too ‘chatty’ for a screen reader user. User testing should be carried out to ensure the appropriate level of feedback is achieved.”
WhyLevel A. The auto-updating clause requires a mechanism to pause, stop, hide or control the frequency of information that starts automatically and is presented in parallel with other content — and the Understanding document notes there is no five-second exception for auto-updating, unlike the moving-and-blinking clause. This is the criterion that makes a cancel control on a long agent run an obligation rather than a nicety, and almost nobody applies it that way.
WhyPrimary source for the tooling lesson. “Web accessibility evaluation tools can not determine accessibility, they can only assist in doing so.” Also: tools cannot check all aspects automatically, human judgement is required, tools sometimes produce false or misleading results, and avoid relying too much on what tools say over the real-life experience of users.
WhySource of the coverage figure, in the vendor’s own words: “With axe-core, you can find on average 57% of WCAG issues automatically.” Treat it as a vendor’s claim about its own product, not an independent measurement. It sits next to the design commitment that produces the ceiling — “It returns zero false positives (bugs notwithstanding)” — and reading the two together is the point: a guarantee of never reporting a false failure necessarily excludes every check requiring judgement.
WhyThe tag vocabulary (wcag2a, wcag2aa, wcag21a, wcag21aa, wcag22aa, best-practice, section508, cat.*) and, more usefully, which groups are disabled by default: WCAG 2.2, AAA, experimental and deprecated. Worth reading for what is absent — there is no rule for aria-live, role="status", or live regions, which is to say 4.1.3 is outside automated reach entirely.
WhyThe accessibility category is a weighted average of audits, weighted by axe user impact assessments, each audit pass or fail with no partial credit. The limitation is not on this page but in Lighthouse’s own default configuration, as the string printed above every accessibility report: “Automatic detection can only detect a subset of issues and does not guarantee the accessibility of your web app, so manual testing is also encouraged.” A vendor disclaiming its own metric inside its own UI is the strongest kind of vendor statement there is.
WhyThe 2026 edition: detected WCAG 2 failures on 95.9% of one million home pages, averaging 56.1 errors per page, with low contrast text at 83.9%, missing alt text at 53.1% and missing form labels at 51%. The caveat is more useful than the headline — only automatically detectable failures are counted, and “absence of detected errors does not indicate that a page is accessible or conformant.”
The ARIA Authoring Practices Guide, the one W3C criterion people misquote when they defend a modal, and WebAIM’s two screen-reader testing articles. The APG is guidance about applying WAI-ARIA and is explicitly not the specification, so every citation from it names an implementation rather than an obligation. WebAIM is a nonprofit that also sells accessibility training.
WhyPrimary source for the role-is-a-promise lesson. Source of the sentence the whole module rests on — “Unlike HTML input elements, ARIA roles do not cause browsers to provide keyboard behaviors or styling” — and of “No ARIA is better than Bad ARIA” and the instruction that testing assistive technology interoperability is essential before using the guide’s code in production. The quoted sentence names keyboard behaviour and styling only; the lesson’s extension of it to focus and tab order is labelled in prose as the course reasoning from that fact, not as a second quotation.
WhyThe four rules of ARIA use, quoted verbatim in the role-is-a-promise lesson. There are four, not five. The status is quoted alongside the rules every time: the formulation is worth having, and a discontinued draft cannot carry the weight of a live standard.
WhyPrimary source for the four-patterns lesson. The definition, the keyboard table (Down Arrow, Alt+Down Arrow, Escape, Enter, Alt+Up Arrow), and the property list. Source of the sentence that explains why focus refuses to move: “DOM focus is maintained on the combobox and the assistive technology focus is moved within the listbox using aria-activedescendant.”
WhyCited in the four-patterns lesson for the tree / treeitem / group structure, the arrow-key model with type-ahead and the optional asterisk, and aria-level, aria-setsize and aria-posinset for nodes not all present in the DOM. Also the source of the sentence most often stated backwards: the tree role “supports the aria-activedescendant property, which provides an alternative to moving DOM focus among treeitem elements.” Moving DOM focus is the baseline that sentence is written from; neither approach is required and neither is forbidden.
WhyThe full focus contract for an overlay, cited across the four-patterns and focus-in-an-overlay lessons: focus into the dialog on open with four cases for where to put it, Tab and Shift+Tab wrapping inside, Escape closing, and focus returning “to the element that invoked the dialog unless either the invoking element no longer exists.” That exception is the one an agent run hits routinely. This contract is the APG’s recommended implementation and carries no conformance obligation of its own, which the lesson states explicitly.
WhyThe cheapest of the four patterns: a control with role=“button”, aria-expanded true or false, optional aria-controls, and both Enter and Space toggling. Cited in the four-patterns lesson, and again as the contrast case for a trace tree, since a pile of disclosures has no level, no set position and no arrow-key model.
WhyThe single-tab-stop rule for composite widgets, and the practical argument between the two focus techniques: “One benefit of using roving tabindex rather than aria-activedescendant to manage focus is that the user agent will scroll the newly focused element into view.” With aria-activedescendant, scrolling the active node into view is the author’s job. Cited in the four-patterns lesson.
WhyPrimary source for the focus-in-an-overlay lesson, and the document that ends the recurring argument about modals: restricting focus to a modal dialog or popover “does not fail the requirements of this criterion, as long as the user knows how to ‘untrap’ the focus and leave that component.” Read it for what it does not say — it forbids trapping and nothing else, so the enter-on-open and return-on-close contract has to be cited from the APG instead.
WhyPrimary source for the screen-reader lesson. The reading and navigation command tables this lesson draws from, the CapsLock modifier recommendation, and the browse-versus-focus-mode distinction that explains most confusing first sessions. Honest about the ramp: “Plan on spending some time (perhaps a few hours) becoming comfortable using NVDA.” The article proposes no minimum command set — the lesson’s “about a dozen” is the course’s own tally and says so.
WhyThe macOS half of the screen-reader lesson: Command+F5 to start, Control+Option as the VO modifier, VO+A to read, VO+U for the rotor, VO+Command+H for the next heading, VO+Space to activate. Source of the caveat that changes what a support claim means: “VoiceOver currently functions best with the Safari web browser.” A screen reader and a browser behave as a pair, so the accessibility-supported line names both.
Why1,539 valid responses collected in December 2023 and January 2024, reporting JAWS 40.5%, NVDA 37.7%, VoiceOver 9.7% as primary screen readers. Cited in the screen-reader lesson together with WebAIM’s own disclaimer — “The sample was not controlled and may not represent all screen reader users” — and explicitly not used to justify which screen readers to learn. The reason given there is that NVDA and VoiceOver are free and already on the machines you own.
Where the published guidance runs out. These sources are listed partly for what they contain and partly for what they demonstrably do not — and three of the four recommendations this module makes are the course’s own construction, with no source behind them at all.
WhyThe reference for polite versus assertive versus off, aria-atomic (default false) and aria-relevant (default “additions text”). Two sentences do most of the work: assertive “will interrupt any announcement a screen reader is currently making” and “can be extremely annoying and disruptive and should only be used sparingly”; and the live region has to carry the attribute before the change occurs — start with an empty region, then change its content in a separate step. Cited in the announcing-the-stream lesson for why a bare polite region is not the fix either.
WhyPrimary source for the announcing-the-stream lesson. Implicit aria-live="polite" and implicit aria-atomic="true" — the second of which is exactly wrong for a token stream, since atomic means re-present the whole region on every change. Also states the rule the interrupting-without-hijacking lesson turns on: do not give focus to a status when its content updates, and if focus must move, a status or other live region is likely not appropriate.
WhyThe mechanism the announce-on-completion pattern is built from: aria-busy="true" tells assistive technology “that it should wait until the modifications or changes are complete before exposing the content to the user.” Note carefully that MDN is documenting an attribute, not endorsing a streaming pattern — the pattern in the announcing-the-stream lesson is this course’s own synthesis and is labelled as such in the lesson body.
WhyPrimary source for the interrupting-without-hijacking lesson. role="alert" “is equivalent to setting aria-live="assertive" and aria-atomic="true"”; the element “does not have to be able to receive focus, as screen readers… will automatically announce the updated content regardless of where keyboard focus is”; and “because of its intrusive nature, the alert role must be used sparingly and only in situations where the user’s immediate attention is required.” The middle sentence is the one that removes the reason for the .focus() call. MDN does not compare alert against a focus-moving pattern — that comparison is the course’s judgement.
WhyCited in the interrupting-without-hijacking lesson for the WCAG glossary definition it restates: changes of context include changes of user agent, viewport, focus, and content that changes the meaning of the page. That definition is what lets you say an agent-initiated focus move is a change of context in the specification’s own vocabulary. 3.2.2 itself prohibits a narrower thing — a context change caused by changing the setting of a component — so it is not the criterion that catches an agent, and the lesson says so rather than over-claiming a violation.
WhyActual testing of aria-live polite and assertive, role="alert", the HTML output element and dynamic aria-describedby across NVDA, JAWS, Narrator, VoiceOver, Orca and TalkBack. The findings are the argument: JAWS treats all live regions as polite, NVDA re-announces content it interrupted, VoiceOver loses content in Braille, Orca does not announce alert at all. He is explicit that the post covers only how live regions are exposed, not whether they are a good idea, and explicit about his own limits — not a daily screen reader user, using built-in Braille viewers rather than hardware. Cited in the announcing-the-stream lesson as evidence of variance, not as a support matrix.
WhyThe practical gotchas: the region must exist when the browser parses the page, clear the region on a 350–500ms timeout between updates to avoid duplicate announcements, keep to one polite and one assertive region per page, and accept that live regions convey no rich semantics — buttons and links inside one are announced as plain text. Her summary of the whole mechanism, “inconsistent and unpredictable,” is corroborated by Roselli’s testing. Cited in the announcing-the-stream lesson.
WhyListed for what it does not say, and it is the single most load-bearing source in this module. Read end to end on 5 September 2026, with no newer draft published: it covers generated alt text, captioning, plain-language conversion and the use of machine learning in accessibility testing, and it contains nothing on announcing streaming or incrementally generated text, nothing on chat interfaces, and nothing on live regions. The announcing-the-stream lesson cites that absence with the date attached, because an editor’s draft is a moving target and the claim is a snapshot rather than a permanent property of the field. Re-verify before repeating it.
Every criterion number on these pages links to the success criterion or its Understanding document. If a number or a level looks wrong, check the resource list and tell your teaching agent — a course about citing the spec correctly has no excuse for citing it wrongly.