Pick a standard, a WCAG target level, a test environment, and the features your product actually has, then get a review list that planning, design, and development can share. Every item carries a practical question, how to check it, and what evidence to record, alongside a status, a note, and an evidence URL. Everything stays in this browser and exports as Markdown or CSV.
Your project details and review status stay in this browser only. Nothing syncs to another device, so export important work as Markdown or CSV.
This checklist is an internal pre-review record. Korean web accessibility certification uses its own process, including page sampling, item-level conformance calculations, expert review, and user testing. Marking every item as passed is not certification and is not 100% conformance.
An accessibility checklist should begin before release QA. Decisions about alternative text ownership, color systems, keyboard interaction, error recovery, and authentication can affect product structure, and resolving them during planning and design is usually cheaper than fixing them after implementation.
Start by naming the standard and target the project will use. Then keep the same checklist through requirements, design review, implementation, and release testing so that decisions and evidence stay connected to the criteria they belong to.
KWCAG 2.2 is a Korean web content accessibility standard organized into four principles, 14 guidelines, and 33 requirements. It does not use A, AA, and AAA levels. WCAG 2.2 organizes success criteria into those three conformance levels, and a WCAG AA target includes both Level A and Level AA criteria.
The standards overlap in purpose, but their numbering, grouping, and some requirements differ. Do not treat one as a direct translation of the other. This builder keeps them as separate datasets: KWCAG generates all 33 requirements, while WCAG generates 31 Level A criteria, or 55 criteria when AA is selected. Level AAA is out of scope, and 4.1.1 Parsing is excluded because it was removed in WCAG 2.2.
Public and private organizations may have different legal, procurement, or certification obligations, but organization type alone does not determine whether a control needs a keyboard interface or an image needs an appropriate text alternative. The selection is therefore recorded as project context and changes the guidance shown, not the technical checklist.
Product features are far more useful for identifying likely non-applicable items. Media, authentication, time limits, gestures, and motion input each flag a specific set of criteria for review.
Level A covers foundational barriers. Level AA adds requirements commonly used as a product accessibility target, including minimum contrast, reflow, text spacing, non-text contrast, focus that is not obscured, and minimum target size. The correct target may be set by policy, contract, or regulation, so the builder does not decide it for the team.
Raising the target from A to AA keeps the status and notes you already recorded on Level A items and adds the AA criteria as not started. Lowering it back to A removes AA items, so the builder first tells you how many of them already carry a record. KWCAG mode has no level control and always includes all 33 requirements.
A product without prerecorded media may not need a caption review, and a product without authentication may not need an authentication criterion. However, a setup answer is not enough to prove that a requirement is inapplicable. Embedded content, an advertisement, or a feature added after launch can change the scope at any time.
The builder therefore highlights candidates but keeps them visible and inside the progress denominator. A reviewer must explicitly choose Not applicable and should record the reason. Broad criteria such as keyboard operation, name, role, value, and overall web application accessibility are never flagged as candidates, because no single feature answer can rule them out.
Planning roles define flows such as error recovery, timing, authentication, redundant entry, and help. Designers specify color, contrast, focus presentation, target size, and non-color cues. Developers implement semantics, keyboard behavior, programmatic names, roles, values, and status announcements.
Many criteria need more than one role. A form label, for example, is named during planning, positioned during design, and associated with its input during implementation. Treat role tags as a handoff path and agree on one final reviewer for each product area.
Review progress measures workflow completion. It is not a conformance score, an accessibility percentage, or a certification prediction. Passed means no issue was found in the reviewed scope; it does not prove that every page, state, browser, and assistive technology combination conforms.
Use Issue to start remediation work, and record the affected screen, reproduction steps, owner, and retest condition in the note. Record a reason for every Not applicable decision so it can be reconsidered when the product changes.
The denominator is the total number of items minus the ones you marked Not applicable. When every item is Not applicable the builder reports that there is nothing to review instead of showing 100%, because a full bar with no denominator reads as completion that never happened.
Automated checks can find missing markup, some contrast problems, and specific structural failures. Human review is still needed to judge alternative text quality, logical focus order, understandable errors, complete non-color cues, and real task completion.
A practical sequence is to classify product features and process requirements during planning, review contrast, color differentiation, target size, and focus design next, inspect HTML structure and keyboard behavior during implementation, test resizing, reflow, and text spacing in the rendered interface, complete key tasks with keyboard-only and screen reader workflows, then fix issues and run regression checks across reused patterns.
The individual Kitfolio checkers support the design review and implementation steps. The checklist never collects their output automatically, so record what you tested and link the fix in the note and evidence fields.
Markdown works well for repository documentation, issues, and readable review notes, grouping items under each review axis with their status, notes, and sources. CSV is useful for spreadsheet filtering, ownership views, and issue counts, and it carries a UTF-8 byte order mark so Korean text opens correctly in Excel.
Both exports contain the complete current checklist regardless of the filters on screen, because the person receiving the file cannot tell which items were hidden. Browser storage is convenient but it is not a durable backup, so export important work regularly, especially before clearing browser data or moving to another device.
It can organize pre-review work, but it is not the official assessment sheet and cannot predict certification. Formal assessment can include page sampling, content-level evaluation, item-level conformance calculations, and user testing. Always confirm the current assessment instructions at the time of application.
Describe the output as a pre-review record together with the scope you tested, the browsers and assistive technology you used, and the date. Do not describe it as proof of certification or as 100% conformance.
Those nine stay in the list with a badge rather than disappearing. Video or a carousel can be added after launch, so they leave the denominator only when a reviewer looks at the real screens and selects Not applicable. Broad items such as keyboard accessibility are never flagged, whatever you answer.
An AA target includes Level A, so there is no need to rebuild. Going back down to A instead asks for confirmation and names how many AA items with a record would be deleted.
30% describes workflow, not conformance. The exported Markdown lists status, note, evidence, and the official source under each axis heading, so the three issues move straight into a remediation backlog.
What it is, who it's for, how it works and why you'd use it.
A web accessibility checklist builder is a browser tool that turns KWCAG 2.2 or WCAG 2.2 requirements into project review tasks, tracks roles, status, notes, and evidence, and exports the checklist as Markdown or CSV.
It is designed for product managers, designers, front-end developers, publishers, and QA specialists coordinating accessibility work from planning through release review.
Choose a standard, WCAG target level, test environment, and the features present in your product. Review the generated items, record status and evidence, filter the list, and export it.
It converts standards into actionable, role-based tasks, highlights likely non-applicable items without hiding them, preserves local progress, and creates a consistent handoff document.