# WCAG 3 Accessibility-Support Sets: Korea's Blank > WCAG 3's March 2026 draft structures accessibility-support sets into a formal clause (§3.2.2) — what its English default leaves blank for Korea's Sense Reader. **Published:** 2026-08-19 | **Updated:** 2026-08-19 --- If you've ever run an accessibility checker, you've probably seen a line somewhere in the results like, "This result was verified on a specific browser and screen reader combination." Every accessibility evaluation starts from some baseline environment. But what exactly counts as that "baseline environment" is something standards documents have rarely defined with any precision. The March 2026 Working Draft of WCAG 3 (3.0) puts a name to this gap — the **accessibility-support set** — and structures it into a formal clause (§3.2.2). The term itself existed in earlier drafts too; what this draft adds is splitting it into a default set and an alternative set, numbering the clause, and giving it a proper place within the conformance requirements. Read the definition closely, though, and you'll find a line stating that the baseline is oriented toward English content. This post walks through exactly what that clause says, and what it means for local assistive technology environments like Sense Reader (센스리더), Korea's dominant local screen reader. One thing up front: this post doesn't offer a conclusion or a course of action. It only confirms that this gap exists in the spec, and lays out where Korea currently stands in relation to it. > **One quick note on notation.** You'll see marks like `§3.2.2` below. `§` is the **section sign**, and it points to a specific section number in a document — `§3.2.2` just means "section 3.2.2." It's a common convention when citing W3C specs, but rare enough in everyday English writing that it can look like a stray symbol at first glance. Just read it as "section" and move on. ## The Old Ambiguity of "Accessibility Supported" This concern isn't new, actually. WCAG 2.x already included a conformance requirement that technologies be used "in a way that is accessibility supported." The problem was that the standard itself never pinned down exactly which browser and assistive technology combination "accessibility supported" was measured against. So in practice, every organization drew its own line — "we support Chrome plus NVDA," say. Depending on which combination you picked as your baseline, the same content could get a different verdict on whether it was accessibility supported. ## WCAG 3 Structures This Into a Formal Clause Picture a scenario first. For a standard to say "build it this way and it counts as accessible," someone actually has to test it. And testing means making decisions: **which browser? Which screen reader? What state are settings like zoom or high contrast in?** Without pinning down those three things, the claim "it works" doesn't even mean anything — content might read fine on Chrome+NVDA and not read at all on Safari+VoiceOver. The accessibility-support set is the name given to **this one bundle of test conditions.** §3.2.2 "Accessibility supported" in the March Draft names this ambiguity, and §3.2.2.1 beneath it defines the concept. An **accessibility-support set** is the combination of **browser, assistive technology, and accessibility settings** used as the test baseline when determining whether an implementation method satisfies a requirement. {{< img src="images/contents/support-set-what.png" alt="Diagram of what makes up an accessibility-support set - a browser (UA), assistive technology (AT), and accessibility settings combine into one bundle of test conditions, which splits into two kinds: a default set that W3C defines and an alternative set that regions or organizations designate separately. The default set isn't defined yet, and no alternative set has been designated either" >}} A few terms travel together here, so let's unpack them all at once. | Term | Meaning | |---|---| | UA (User Agent) | Browser — Chrome, Safari, Firefox, and the like | | AT (Assistive Technology) | Screen readers, screen magnifiers, switch input devices, and similar tools | | AGWG | Accessibility Guidelines Working Group — the W3C working group that produces WCAG | | Conformance claim | A document publicly stating "our service meets this standard" | | Editor's note | A note the spec authors leave in a draft, like "this part isn't decided yet" | Feel free to come back to this table whenever an unfamiliar abbreviation shows up — no need to memorize it. The document splits this set into two kinds: a **default accessibility-support set** and an **alternative accessibility-support set**. The default set is described as a combination of commonly used browsers and assistive technologies that support English content, and it's explicitly scoped, for now, to **HTML implementation methods** (the text only notes that sets for other technologies, like mobile or VR, might be added later). There's one more condition attached. **Core** is the most fundamental bundle of requirements in WCAG 3, and the AGWG applies one rule when adding an item to it: there must be **at least one HTML implementation method that actually works within the default set** — and that has to be true as of the time of publication. Put differently: a requirement that's merely "correct in theory" doesn't get into Core. Only one that's been confirmed to actually work within the default set gets in. A reasonable principle — but this is exactly where it runs into the earlier problem. The bar used for that verification is **English content.** There's a piece here that lands directly on practitioners, too. The draft requires that a **conformance claim state which accessibility-support set was used.** You can't just say "we meet the accessibility standard" — you have to say which environment you verified it in. Going further, it recommends disclosing that set in a public accessibility statement as well, in cases like: - A service running on a **closed network** that's not reachable from outside - Content built with a non-HTML technology (native apps, PDFs, and so on) - A region that depends on browsers or assistive technologies outside the default set That last bullet isn't someone else's problem for a domestic service dealing with a Korean-language environment. It's worth pausing on the word "method" too. WCAG 3 sets out to provide a concrete, "do it this way and it counts as met" implementation method for each requirement, **broken out by technology.** The same requirement might have a different method for HTML than it does for PDF. But for a method to be recognized as "actually working," it has to be demonstrated somewhere. **Deciding what that "somewhere" is is exactly what the accessibility-support set does.** So these concepts are all chained together. The support set has to be settled before a method can be verified, and the method has to be verified before a requirement can go into Core. If the very first link is empty, everything downstream ends up floating without ground under it. And yet what that default set actually is comes down, right now, to an editor's note that says only this: **not yet defined.** The concept has been built; the substance inside it hasn't. You can guess why this became an explicit concept. If you've used automated accessibility checkers, you've probably seen the same page get slightly different results from different tools — or even from the same tool, depending on version or runtime environment. Which browser and assistive technology combination the test ran against affects the outcome, and WCAG 2.x never required that baseline to be documented. Spelling out the accessibility-support set concept at least lays the groundwork for recording — and comparing — exactly what baseline a result was verified against. ## The Questions an English-First Default Raises The fact that the default set is defined as a combination that "supports English content" carries real practical implications on its own. For a requirement to count as verified, it needs to work within the default set — and if that default set is built around an English-content environment, issues specific to Korean content might not get verified the same way. Think of things like how a Korean screen reader reads out individual jamo (자소, the consonant/vowel components of Hangul characters), or how focus moves during Hangul input. It's a bit like watching a foreign film with no subtitles — you can see the screen just fine, but the explanation you actually need was written for a different language's context. **Sense Reader** is the screen reader that's widely used locally in Korea — a tool that exists outside the commonly cited international list of JAWS, NVDA, and VoiceOver. That alone means the makeup of browser-and-assistive-technology combinations here differs from the standard English-speaking list. Korea also already has a national standard, **KWCAG 2.2** (KS X OT0003, revised December 2022, based on WCAG 2.1), along with a separate web accessibility quality certification system built around it. So the question of "who decides the baseline environment" isn't new to Korea, either — a national standard and the certification system that verifies against it have coexisted here for a while. None of this is something we can settle definitively right now, though. W3C hasn't yet said what the default set will actually contain, so even the question of "will Sense Reader be included or not" can't be answered yet. ## The "Regional Regulators Can Define Alternatives" Clause There's another notable line in the March Draft. When the default accessibility-support set doesn't provide the support that's needed, not just individuals or organizations, but **regional regulators**, can also designate an alternative accessibility-support set. Unpacking what this clause means: WCAG 3 isn't claiming that a single English-content-based default set will cover the whole world. Instead, it leaves the door open for regions or organizations where that default doesn't fit to establish their own baseline. Whether it's a national standards body or an industry association, the spec already provides theoretical grounds for declaring, "in our environment, this browser-and-AT combination is the baseline." The term "regional regulators" is worth unpacking, too. It refers to bodies that oversee accessibility-related law and policy in a given country or region — in Korea's case, this could describe the body that manages and revises KWCAG. This kind of regionalization isn't unfamiliar territory for web accessibility standards, honestly. WCAG 2 itself gave rise to standards adapted to local context in country after country — KWCAG in Korea, Section 508 in the US, EN 301 549 in Europe. WCAG 3's "regional regulators" clause reads as a signal that this same pattern will continue within the new accessibility-support set concept. That said, this clause only opens up a possibility — it isn't a statement that anyone has actually decided to do this. As of this writing, no Korean institution has publicly announced plans to build an alternative accessibility-support set for WCAG 3. The clause has opened the door; nobody has decided yet who's going to walk through it. ## How These Gaps Might Get Filled To summarize, here's the shape of the gaps sitting in the spec right now. - **The default set itself is empty**: There's only a directional statement — English-content-based — with no concrete list of browsers and assistive technologies yet. How W3C plans to fill that list — based on usage statistics, say, or through consultation with major platform vendors — isn't specified in the current draft either. - **Who can fill it is left wide open**: Individuals, organizations, and regional regulators are all explicitly named as parties who can designate an alternative set. That range covers everything from a single company setting its own support set for internal QA purposes, to a national standards body formally designating an alternative set. - **No actual case has filled it in yet**: Neither the default set nor any alternative set has been fleshed out as of now. Having all three of these gaps open at once is the honest state of the current draft. {{< img src="images/contents/support-set-gaps-en.png" alt="A diagram of three gaps branching from the accessibility-support set concept - the undefined default set, the alternative set with no filled example yet, and Korea's position, which has Sense Reader and KWCAG 2.2 but no announced plan" >}} Looking at these three gaps side by side, it feels like the more important step right now isn't debating who should fill them, but simply being aware that they exist. If we settle on an answer for an unfilled gap too early, we might just have to reverse course once W3C actually announces the default set. ## One-Page Summary - **Accessibility-support sets** are WCAG 3 (3.0) §3.2.2's attempt to explicitly define a concept that's been fuzzy since WCAG 2.x: "accessibility supported." - The **default set** only has a stated direction — common browsers and assistive technologies that support English content — its concrete definition is **still empty**, marked only by an editor's note. - Core requirements require at least one HTML method that works within the default set, and it's worth noting that this verification bar is currently English-centered. - The draft includes a clause letting individuals, organizations, and **regional regulators** alike designate alternative accessibility-support sets. - Korea has a **Sense Reader**-centered AT landscape and an existing national standard, **KWCAG 2.2** — so this gap isn't someone else's problem. - That said, no institution in Korea has publicly announced plans to build an alternative set — right now calls for watching, not concluding. --- {{< faq "Quick answers" >}} --- ## More in This Series - [The Dawn of WCAG 3.0: Why We Need New Guidelines]({{< relref "/posts/wcag-3-era-why-new-guidelines" >}}) - [WCAG 3.0 Structure Anatomy: From Success Criteria to Outcomes]({{< relref "/posts/wcag-3-structure-outcomes" >}}) - [WCAG 3.0 Conformance Model: Moving Beyond A/AA/AAA]({{< relref "/posts/wcag-3-scoring-conformance" >}}) - [Atomic Tests vs. Holistic Tests: A New Testing Approach]({{< relref "/posts/wcag-3-atomic-holistic-tests" >}}) - [Assertions: A New Unit for Accessibility Evaluation]({{< relref "/posts/wcag-3-assertions" >}}) - [WCAG 3.0 Expanded Scope: Beyond the Web]({{< relref "/posts/wcag-3-expanded-scope-beyond-web" >}}) - [WCAG 3 Migration: Do You Need It Yet? Moving On from WCAG 2.2]({{< relref "/posts/wcag-3-migration-strategy" >}}) - [WCAG 3 Status Check: A Complete Rundown of the March 2026 Draft]({{< relref "/posts/wcag-3-status-2026" >}}) ## References - [W3C Accessibility Guidelines (WCAG) 3.0 Working Draft (2026-03-03)](https://www.w3.org/TR/wcag-3.0/) - [WCAG 3.0 Explainer](https://www.w3.org/TR/wcag-3.0-explainer/) - [Korean Web Content Accessibility Guidelines (KWCAG) 2.2 — KS X OT0003 (National Radio Research Agency)](https://www.rra.go.kr/ko/reference/kcsList_view.do?nb_seq=5247&cpage=1&nb_type=6&kcs_select0=ALL&kcs_select1=ALL&kcs_select2=%C1%A4%BA%B8%B1%E2%BC%FA&searchCon=nb_name&searchTxt=%C1%A2%B1%D9%BC%BA) - [The Complete Guide to KWCAG 2.2 — 4 Principles, 14 Guidelines, 33 Success Criteria]({{< relref "/posts/kwcag-22-guide" >}}) --- > **Note**: This post is based on the **W3C Working Draft dated March 3, 2026**. The accessibility-support set is an early-stage concept whose default value isn't even defined yet within the document itself, so its content may change substantially in later drafts.