조달과 VPAT/ACR 실무

조달 생애주기와 접근성

Accessibility Across the Procurement Lifecycle

조직이 쓰는 소프트웨어의 대부분은 구매·구독하는 제품입니다. 아무리 자체 개발물이 접근 가능해도, 조달한 HR 시스템·협업 도구·키오스크가 접근 불가능하면 조직의 접근성은 무너집니다. 그래서 조달은 접근성 거버넌스의 핵심 통제 지점입니다.

Most software an organization uses is bought or subscribed to. However accessible your own builds are, an inaccessible procured HR system, collaboration tool, or kiosk breaks organizational accessibility. Procurement is therefore a key control point of accessibility governance.

생애주기별 통합: ① 요구 정의 — RFP(제안요청서)에 접근성 요구사항(예: WCAG 2.2 AA, EN 301 549)과 ACR 제출 의무를 명시 ② 평가 — 접근성을 채점 기준에 배점하고 ACR·데모를 검토 ③ 계약 — 접근성 조항, 결함 시정 일정, 검수 권리를 포함 ④ 도입 후 — 업데이트마다 재검증하고 사용자 피드백 채널을 운영.

Integration across the lifecycle: ① Requirements — state accessibility requirements (e.g., WCAG 2.2 AA, EN 301 549) and mandatory ACR submission in the RFP ② Evaluation — weight accessibility in scoring and review ACRs and demos ③ Contract — include accessibility clauses, remediation timelines, and audit rights ④ Post-deployment — revalidate on updates and run a user feedback channel.

Section 508(미국 연방)과 EN 301 549(EU)가 조달 접근성의 양대 기준이며, 한국도 공공 조달에서 접근성 요구가 확산되고 있습니다. 조달 담당자·계약 담당자 교육이 프로그램의 성패를 좌우합니다.

Section 508 (US federal) and EN 301 549 (EU) are the two flagship procurement standards, and accessibility requirements are spreading in Korean public procurement as well. Training procurement and contract officers often determines program success.

ACR 읽기 — 신뢰도 평가

Reading an ACR — Judging Credibility

ACR을 받았다면 먼저 메타데이터를 확인합니다: 어떤 VPAT 에디션(508/EU/WCAG/INT)과 버전인지, 평가 대상 제품·버전·범위가 무엇인지, 평가 일자와 평가 방법(자체 평가인지 제3자 평가인지, 어떤 보조기술로 테스트했는지)이 명시되어 있는지.

When you receive an ACR, check the metadata first: which VPAT edition (508/EU/WCAG/INT) and version; the evaluated product, version, and scope; the evaluation date; and the method — self-assessment or third-party, and which assistive technologies were used in testing.

신뢰도의 신호: 모든 항목이 '지원(Supports)'로만 채워진 문서는 오히려 의심스럽습니다 — 성숙한 공급업체는 '부분 지원'을 구체적 비고(어떤 화면에서 어떤 문제가 있고 언제 고칠 예정인지)와 함께 솔직하게 씁니다. 비고 없이 등급만 나열한 ACR, 오래된 제품 버전 기준의 ACR, 평가 방법이 불명확한 ACR은 재요청 대상입니다.

Credibility signals: a document showing 'Supports' on every row is itself suspicious — mature vendors write honest 'Partially Supports' entries with specific remarks (which screens, what issues, when fixes are planned). ACRs with ratings but no remarks, ACRs based on outdated product versions, and ACRs with unclear methodology warrant a re-request.

주장 검증과 계약 조항

Verifying Claims and Contract Clauses

ACR은 자가 보고 문서이므로 검증이 필요합니다. 실무 방법: 후보 제품의 핵심 과업 3~5개를 골라 키보드 전용·화면낭독기로 샘플 테스트를 수행하고, 공급업체에 보조기술 시연 데모를 요청하며, 필요하면 제3자 감사 보고서를 요구합니다. 평가 단계의 짧은 테스트가 도입 후 발견되는 값비싼 문제를 예방합니다.

Because an ACR is self-reported, verification matters. Practical methods: pick 3–5 core tasks in the candidate product and run sample tests keyboard-only and with a screen reader; request a vendor demo using assistive technology; and where needed, ask for a third-party audit report. A short test at evaluation prevents expensive post-deployment discoveries.

계약 조항의 요소: 준수 기준과 버전(WCAG 2.2 AA 등) 명시, 신규 릴리스에 대한 지속 준수 의무, 결함 발견 시 시정 일정(SLA), 시정 실패 시 구제 수단(위약·해지), 접근성 문의 대응 창구, 그리고 갱신 시점의 ACR 재제출 의무. 조항이 없으면 도입 후 발견된 문제의 비용은 구매자가 떠안게 됩니다.

Contract clause elements: the named standard and version (e.g., WCAG 2.2 AA), continued conformance obligations for new releases, remediation timelines (SLAs) for defects, remedies for failure (penalties, termination), an accessibility support contact, and re-submission of ACRs at renewal. Without clauses, the buyer absorbs the cost of problems found after deployment.