접근성 관리 전략

접근성 성숙도 모델

Accessibility Maturity Models

접근성 성숙도 모델은 조직의 접근성 수준을 단계적으로 평가하고 다음 단계로의 로드맵을 제공합니다. 일반적 단계: 초기(Ad hoc) — 체계 없이 개별 대응 → 계획(Planned) — 정책·목표 수립 시작 → 관리(Managed) — 프로세스 통합과 모니터링 → 정착(Embedded) — 조직 문화의 일부 → 최적화(Optimized) — 지속적 개선과 혁신.

Accessibility maturity models assess an organization's accessibility level in stages and provide a roadmap forward. Typical stages: Ad hoc — unsystematic, case-by-case reactions → Planned — policies and goals emerging → Managed — integrated into processes with monitoring → Embedded — part of organizational culture → Optimized — continuous improvement and innovation.

W3C도 접근성 성숙도 모델(Accessibility Maturity Model)을 발행해 커뮤니케이션, 지식·역량, 지원, 인사, 조달, 문화 등 차원별로 성숙도를 진단하게 합니다. 성숙도 평가의 목적은 등급 매기기가 아니라, 일회성 프로젝트에서 지속 가능한 프로그램으로 옮겨가는 경로를 설계하는 것입니다.

The W3C also publishes an Accessibility Maturity Model that assesses dimensions such as communications, knowledge and skills, support, personnel, procurement, and culture. The point of maturity assessment is not grading but designing the path from one-off projects to a sustainable program.

정책과 거버넌스

Policy and Governance

효과적인 접근성 프로그램은 경영진의 후원(sponsorship)에서 출발합니다. 접근성 정책에는 적용 범위, 목표 표준(예: WCAG 2.2 AA), 역할과 책임, 예외 처리 절차, 검토 주기가 명시되어야 합니다. 정책 없이 개인의 선의에 의존하는 접근성은 담당자가 떠나면 함께 사라집니다.

An effective accessibility program starts with executive sponsorship. An accessibility policy should specify scope, target standard (e.g., WCAG 2.2 AA), roles and responsibilities, exception procedures, and review cycles. Accessibility that relies on individual goodwill without policy disappears when that person leaves.

접근성 성명(Accessibility Statement)은 사이트의 준수 수준, 알려진 한계, 피드백 연락처를 공개하는 문서로, EU 공공 부문에서는 법적 의무이고 그 외에도 신뢰와 책임성의 표지로 널리 권장됩니다. 조직 규모가 커지면 접근성 사무국(Accessibility Office)이나 전담 리더(예: Chief Accessibility Officer)를 두어 거버넌스를 중앙화합니다.

An Accessibility Statement publicly discloses a site's conformance level, known limitations, and a feedback contact — legally required for the EU public sector and widely recommended elsewhere as a marker of trust and accountability. As organizations grow, an Accessibility Office or dedicated leader (e.g., a Chief Accessibility Officer) centralizes governance.

조달과 VPAT/ACR

Procurement and VPAT/ACR

조직이 사용하는 ICT의 상당수는 직접 만들지 않고 구매합니다. 그래서 조달 단계의 접근성 검증이 중요합니다. VPAT(Voluntary Product Accessibility Template)는 공급업체가 자사 제품의 접근성 적합성을 기준 항목별로 자가 보고하는 표준 양식이고, 작성 완료된 문서를 ACR(Accessibility Conformance Report)이라 부릅니다.

Much of an organization's ICT is bought, not built — which makes accessibility verification at procurement critical. The VPAT (Voluntary Product Accessibility Template) is the standard form vendors use to self-report their product's conformance criterion by criterion; the completed document is an ACR (Accessibility Conformance Report).

VPAT에는 참조 표준에 따라 508, EU(EN 301 549), WCAG, 통합(INT) 네 가지 에디션이 있습니다. 각 기준을 '지원(Supports)', '부분 지원(Partially Supports)', '미지원(Does Not Support)', '해당 없음(Not Applicable)'으로 평가하며, 솔직하고 구체적인 비고가 문서의 신뢰도를 결정합니다. 조달 담당자는 ACR을 요구하고, 주장 검증(데모·샘플 테스트)과 계약상 접근성 조항으로 보완해야 합니다.

VPAT comes in four editions by reference standard: 508, EU (EN 301 549), WCAG, and INT (combined). Each criterion is rated 'Supports', 'Partially Supports', 'Does Not Support', or 'Not Applicable' — honest, specific remarks determine the document's credibility. Procurement officers should require ACRs and supplement them with verification (demos, sample testing) and contractual accessibility clauses.

감사와 모니터링

Auditing and Monitoring

접근성 감사에는 세 축이 있습니다. 자동화 테스트(axe, WAVE, Lighthouse)는 빠르고 반복 가능하지만 전체 이슈의 약 30~40%만 감지합니다. 수동 테스트(키보드 탐색, 화면낭독기, 확대·대비 점검)는 자동화가 놓치는 문제를 찾습니다. 장애인 사용자 테스트는 실제 과업 수행 가능성과 사용성을 검증합니다. 최선의 접근은 세 가지의 병행입니다.

Accessibility auditing has three pillars. Automated testing (axe, WAVE, Lighthouse) is fast and repeatable but detects only about 30–40% of issues. Manual testing (keyboard navigation, screen readers, zoom and contrast checks) finds what automation misses. Testing with disabled users validates real task completion and usability. The best approach combines all three.

감사는 일회성 이벤트가 아니라 주기적 모니터링으로 운영되어야 합니다. 릴리스 파이프라인에 자동 검사를 통합하고(회귀 조기 차단), 주요 사용자 여정에 대해 정기 수동 감사를 수행하며, 발견 이슈는 심각도(차단/중대/경미)와 사용자 영향 기준으로 우선순위를 정해 백로그로 관리합니다.

Auditing should be periodic monitoring, not a one-off event: integrate automated checks into the release pipeline (catching regressions early), run scheduled manual audits of key user journeys, and manage findings in a backlog prioritized by severity (blocker/major/minor) and user impact.

접근성 문화 만들기

Building an Accessibility Culture

지속 가능한 접근성은 문화에서 나옵니다. 핵심 전략: 팀마다 접근성 챔피언을 두어 지식을 분산시키고, 디자인·개발·QA 각 단계에 접근성을 통합하며(Shift Left — 초기 단계로 앞당기기), 역할별 맞춤 교육(디자이너에겐 대비·포커스, 개발자에겐 시맨틱·ARIA)을 정기적으로 실시합니다.

Sustainable accessibility comes from culture. Key strategies: place accessibility champions on each team to distribute knowledge; integrate accessibility into design, development, and QA (Shift Left — moving it earlier); and run role-specific training regularly (contrast and focus for designers, semantics and ARIA for developers).

장애인 사용자 관점의 페르소나와 실제 사용자 참여는 공감을 넘어 요구사항을 구체화합니다. 채용·인사에서도 장애인 고용과 접근 가능한 사내 도구가 문화의 일부입니다. 마지막으로, 접근성을 품질의 정의(Definition of Done)에 포함시키는 것 — '접근성 검수 전에는 완료가 아니다' — 이 문화 정착의 가장 실질적인 장치입니다.

Personas representing disabled users — and better, real user participation — turn empathy into concrete requirements. Hiring people with disabilities and providing accessible internal tools are part of the culture too. Finally, the most practical lever: include accessibility in the Definition of Done — 'not done until it passes accessibility review.'