Before building a component, what must be followedis listed along with its normative basis. The deliverable is a design input — since there is no code yet, there is nothing to grade either.
SCs apply not to components but to content properties. So the filter goes name → property → SC, two hops.
Because the middle hop is the property, even an unfamiliar name (Coachmark, SegmentedControl) is handled.
The deliverable is reports/<component>.md 한 부다.
Terminology
If one word is used with two meanings, the document cannot be read. The vocabulary below is used.
| 말 | 뜻 |
|---|---|
| Base implementation | base-ui or a browser-native element. These two |
| Evidence | What backs a delegation. Observation(empirical) or Specification, only these two |
| Exhaustive | Judging without omission. sc-map.md 60행, properties.md 23 items are the target |
| APG pattern | A W3C widget type. Written with the prefix APGattached to "pattern" |
| Pattern | "Pattern" without a prefix has the meaning of root CONTEXT.md section 2 (a design system's design rules) |
| Widget contract | What this widget promises to AT. 6 slots: role, state, properties, keys, focus, name. Step 5 위임is the judgment that the base implementation already fulfills that contract |
| Notation / part composition | The manner provided by base-ui. CONTEXT.md Section 1 vocabulary (compound, flat, part) |
| Consumer | A developer who adopts and uses vapor |
| End user | A person who uses the screen with a screen reader or keyboard |
| Reconnaissance | Reading only documentation and API references |
| Empirical testing | Operating the demo in a browser to observe the results |
| Specification check | Reading the HTML-AAM, MDN, and WAI-ARIA specifications |
The name of the responsibility section is vapor 책임.
Procedure
0. Reconnaissance — base-ui documentation
https://base-ui.com/react/components/<컴포넌트> (kebab-case) and its API reference.
It is done once the four items are filled in.
- Is there a page for that component — if not, the base implementation is a native element or does not exist
- Notation and part composition — compound or flat, and what the part list is
- Whether a native element is used — whether it uses
<button>·<dialog>·<input>internally - A prop that can overturn the judgment — extract it as a list
No. 4 is the input to the Step 5 empirical plan. A real example where a single prop combination flips an SC judgment is references/verify.md
in the § empirical examples. No. 3 is also cheap — the fact that base-ui Dialog does not use the native <dialog>was a premise for several SC judgments.
1. Properties — Look Only at Properties
references/properties.md(23 property vocabulary terms, discriminating questions, inference rules) and extract the tag from the component name. All 23with attached/not attached and each having a different one-line rationale, and that is it.
At this step, read only properties.md. If you read the Step 2 APG table first, the visual axis Visual Axis
tag (ui-boundary·text·state-visual·pointer-target) is missed. The step boundary is the device that prevents that contamination.
For names whose properties clearly diverge, ask immediately here — Menu, and depending on whether it is a navigation menu or an action menu, the APG pattern to look up in Step 2 changes (Menubar / Menu). The remaining checks are gathered at the Step 2 gate.
2. Widget Contract + Gate
Fill in the 6 cells with the APG pattern (https://www.w3.org/WAI/ARIA/apg/patterns/) and the MDN ARIA role documentation.
If each cell has content or "none + reason", that is it.
| 칸 | What it contains |
|---|---|
| role | Role attached to each part |
| State | aria-expanded aria-checked and other dynamic attributes |
| Attributes | aria-controls aria-valuenow and other static attributes |
| Keyboard interaction | Keys and their results. All APG keyboard tables |
| Focus management rules | Entry point, return, roving tabindex |
| Accessible name | Where the name comes from (child text,aria-label) |
If there is no APG pattern,(card badge skeleton spinner text callout floating-bar)
state "no APG pattern", and if there is a role, fill it from the MDN ARIA role documentation — the MDN role documentation has a list of required attributes not in APG. If that is missing in spinner, the 4.1.2 requirement narrows to "just give a role".
For components with no pattern, proceed on properties alone. Borrowing a similar APG pattern puts inference in the place of evidence
— spinner: applying the Progress pattern forces a aria-valueminthat does not exist as a requirement.
Gate — When It Is Not in base-ui
Of the 42 vapor components, 22 have no base-ui counterpart. In that case, whether to implement with a native element or a custom oneis recommended. There is one basis — how many of the above 6 cells the native element fills. Look up HTML-AAM and MDN at that time.
breadcrumb— Even when there is an APG pattern,<nav><ol><a>gives almost all of role, structure, and keyboard → nativesegmented-control—<input type=radio>gives all of role, state, and arrow movement → nativemulti-select—<select multiple>exists but the required interaction differs → custom
At the end of this step, get user confirmation once. Step 1 shows the property results together with the above recommendation. If base-ui is present, only the properties are shown. The gate check is this one time — only the branching question of Step 1 (names whose properties clearly diverge) is a separate exception.
3. SC filter — the trigger is a property
references/sc-map.mdScan (the SC exhaustive → property reverse-mapping table. The core of this skill) and adopt rows whose trigger-column tags overlap with the Step 1 results in at least one place. Rows whose trigger is 전체are adopted unconditionally.
Judge all 60 rows. Whether adopted or excluded, every row has a result, and it ends when there are 0 unjudged rows. The adopted count and excluded count go into the Step 6 verification.
The widget contract is not a trigger — it is used for cross-verifying property omissions and as the source of requirement sentences. If the contract is used as a trigger, time axisdisappears entirely (it is in neither APG nor base-ui. The list is owned by sc-map.md).
Use only the rows in the table. Since the table is exhaustive for WCAG 2.2 A/AA and KWCAG, an SC not in the table is either not A/AA or does not exist.
4. Four responsibility sections
Divide each adopted SC into four sections. It ends when sections are attached to all adopted SCs.
| Section | What it contains |
|---|---|
| Delegated to the underlying implementation | Guaranteed by base-ui or a native element |
| Implemented by vapor itself | vapor guarantees it to the end |
| Joint (channel) | vapor opens the channel and the consumer fills in the content |
| Consumer | Guaranteed by the place of use |
sc-map.mdThe responsibility column of 컴포넌트 / 공동 / 소비자 is these three. 컴포넌트branches into two here, and, which one it is is determined by the Step 5 evidence.
공동(통로)은 Translate it as "which prop/part is needed" and write it down. This section is precisely the prop design list.
Write requirements down to the normative level. "3:1 or higher" is as far as this skill goes; which token to use is a design decision.
5. Evidence collection — measurement or specification confirmation
references/verify.md. If the underlying implementation is base-ui, measure it; if it is a native element, confirm the specification. 기반 구현체 위임과 vapor 자체 구현 It ends when a judgment term is attached to all SCs in the section.
Delegation requires evidence. Write only SCs with evidence as delegated, and leave the rest as 확인 불가.
6. One document
references/report-template.mdFollow the structure of reports/<component>.mdexactly and write it in
. The body contains only the requirements table. The appendix contains the rationale and judgments — ① properties → ② widget contract → ③ exclusion list → ④ design decisions.
In the header, it ends when the 3 verification lines are correct. The formula and what each line catches are owned by report-template.md.
If a reason arises to change the skeleton, fix the template and align existing documents too.