조달 프로세스와 ACR

조달 수명주기와 접근성

Accessibility Across the Procurement Lifecycle

조직이 쓰는 웹 솔루션의 상당수는 직접 만들지 않고 사들입니다 — CMS, 채팅 위젯, 결제 모듈, 분석 도구, LMS. 사들인 컴포넌트의 접근성 결함은 그대로 내 사이트의 적합성 실패가 되므로('전체 페이지' 요구사항), 조달 단계의 통제가 필수입니다.

Much of an organization's web stack is bought, not built — CMSs, chat widgets, payment modules, analytics, LMSs. A purchased component's accessibility defects become your site's conformance failures (the 'full pages' requirement), so procurement-stage control is essential.

수명주기별 체크포인트: ① 요구사항 정의 — RFP에 접근성 요구(WCAG 2.1/2.2 AA, EN 301 549 등)와 증빙 요구를 명시, ② 후보 평가 — ACR 검토와 핵심 시나리오 자체 테스트, 데모에 스크린 리더·키보드 시연 요구, ③ 계약 — 접근성 보증 조항, 결함 수정 SLA, 향후 버전의 유지 의무, ④ 도입 후 — 통합 검증(내 사이트 맥락에서 재테스트)과 벤더 결함 보고 채널 운영. 미국 연방 조달의 Section 508, EU 공공 조달의 EN 301 549가 이 절차를 법제화한 대표 사례입니다.

Lifecycle checkpoints: ① requirements — state accessibility requirements (WCAG 2.1/2.2 AA, EN 301 549) and required evidence in the RFP; ② vendor evaluation — review ACRs, test key scenarios yourself, require screen reader and keyboard demos; ③ contract — accessibility warranty clauses, defect-fix SLAs, obligations for future versions; ④ post-adoption — integration verification (retest in your site's context) and a vendor defect-reporting channel. US federal procurement under Section 508 and EU public procurement under EN 301 549 are the canonical legal embodiments.

VPAT과 ACR 읽는 법

Reading VPATs and ACRs

VPAT(Voluntary Product Accessibility Template)은 ITI가 배포하는 '빈 양식'이고, 벤더가 이를 채워 발행한 결과물이 ACR(Accessibility Conformance Report)입니다. VPAT 에디션은 참조 표준에 따라 WCAG, 508, EU(EN 301 549), INT(통합)로 나뉩니다. ACR은 성공 기준별로 적합성 수준을 표기합니다: 지원(Supports), 부분 지원(Partially Supports), 미지원(Does Not Support), 해당 없음(Not Applicable).

The VPAT (Voluntary Product Accessibility Template) is the blank form published by ITI; the ACR (Accessibility Conformance Report) is what a vendor produces by completing it. VPAT editions track reference standards: WCAG, 508, EU (EN 301 549), and INT (combined). An ACR rates each success criterion: Supports, Partially Supports, Does Not Support, or Not Applicable.

읽을 때 볼 것: 평가 방법(자체 평가인가, 제3자 감사인가, 어떤 도구·AT로 테스트했는가), 문서 날짜와 제품 버전(오래된 ACR은 현재 버전을 대변하지 못함), '부분 지원' 항목의 비고란(어떤 기능이 어떻게 실패하는지 구체적인가), 전부 'Supports'로만 채워진 문서(현실적으로 드물어 신뢰성 의심 신호). 비고가 구체적이고 부분 지원을 정직하게 기재한 ACR이 오히려 신뢰할 수 있는 문서입니다.

What to look for: the evaluation method (self-assessment or third-party audit; which tools and AT were used), document date and product version (a stale ACR doesn't represent the current release), the remarks on 'Partially Supports' rows (do they specify which features fail and how), and documents marked 'Supports' throughout (realistically rare — a credibility red flag). An ACR with specific remarks that honestly records partial support is the more trustworthy document.

접근성 전문가의 역할과 자체 검증

The Expert's Role and Independent Verification

조달에서 접근성 전문가(WAS 역할)의 일: RFP의 접근성 요구사항 작성, 벤더 ACR의 기술 검토(주장과 증거의 대조), 후보 제품의 핵심 과업 자체 테스트(키보드·스크린 리더로 대표 시나리오), 계약 조항 자문, 도입 후 통합 검증과 결함 우선순위 판정. 전문가는 '문서 심사자'가 아니라 '검증자'입니다.

The accessibility expert's procurement work: writing the RFP's accessibility requirements, technically reviewing vendor ACRs (claims versus evidence), independently testing key tasks on candidate products (representative scenarios with keyboard and screen reader), advising on contract clauses, and post-adoption integration verification with defect prioritization. The expert is a verifier, not a paperwork reviewer.

ACR은 출발점이지 보증이 아닙니다: 자체 평가 ACR은 낙관적으로 치우치기 쉽고, 테스트된 버전·환경이 내 도입 환경과 다를 수 있으며, '제품 자체'의 적합성이 '내 사이트에 통합된 상태'의 적합성을 의미하지 않습니다(테마 커스터마이즈, 설정, 함께 쓰는 스크립트가 결과를 바꿈). 따라서 핵심 제품은 반드시 대표 시나리오의 자체 테스트로 ACR 주장을 표본 검증하고, 통합 후 재테스트합니다.

An ACR is a starting point, not a guarantee: self-assessed ACRs skew optimistic; the tested version and environment may differ from yours; and conformance of 'the product itself' is not conformance of 'the product integrated into your site' (theming, configuration, and co-resident scripts change outcomes). So spot-check ACR claims by testing representative scenarios on critical products, and retest after integration.