EAA가 시행된 지 1년이 되었지만, 대부분의 팀은 여전히 ​​규정 준수를 입증하지 못하고 있습니다.

On 2025년 6월 28일유럽 ​​접근성법이 시한에서 시행 단계로 넘어갔습니다. 벌써 1년도 더 전의 일입니다. 

더 이상 긴급하게 느껴지지 않는다면, 그건 정상입니다. 눈에 띄는 문제가 발생하지 않으면 마감일은 금세 잊혀지기 마련입니다. 하지만 접근성 문제는 서버 장애처럼 갑자기 발생하는 것이 아닙니다. 그 결과는 소송, 감사 실패, 구매 과정에서의 계약 지연 등 나중에 드러나게 되는데, 결국 근본적인 원인은 거의 항상 같습니다. 누군가가 당신이 만든 것을 사용할 수 없었고, 아무도 그 문제를 제때 발견하지 못했던 것입니다. 

하지만 이 모든 것의 진정한 목적을 잊지 말아야 합니다. 단순히 감사관을 만족시키기 위한 것이 아닙니다. 실제 사용자가 제품을 활용할 수 있는지 여부가 핵심입니다. 

아버지의 가장 친한 친구분은 태어날 때부터 시각 장애인이십니다. 그분이 부엌에서 요리하는 모습을 보면, 모든 표면과 도구를 '느낄' 수 있기 때문에 시력이 있는 사람들보다 훨씬 빠르고 깔끔하게 재료 손질을 하시는 것을 알 수 있습니다.  

만약 그에게 아이폰을 건네주어 은행 앱으로 요금을 결제하게 한다면, 그동안 쌓아온 숙련도는 전혀 통하지 않을 겁니다. 칼은 무게와 질감이 있어 조작감을 알려주지만, 터치스크린은 엄지손가락이 "이체"를 눌렀는지 "취소"를 눌렀는지 느낄 방법이 없습니다. 그가 결제를 완료할 수 있느냐 없느냐는 그의 기술과는 아무런 상관이 없습니다. 결국 앱을 만든 팀이 그를 위해 제대로 테스트를 했는지에 달려 있는 거죠. 

법 집행은 사회가 애초에 그런 질문을 제기하도록 강요하는 방식입니다. 하지만 그 질문 자체는 사실 법 집행에 관한 것이 아니었습니다. 그 질문의 핵심은 바로 그 사람, 그리고 그와 같은 모든 사람들에 관한 것이었습니다. 

하지만 이는 법 집행의 의미를 잘못 이해한 것입니다. 법 집행은 특정 시점에 이루어지는 것이 아니라 지속적인 조치입니다. 

단속반은 당신이 한 번 합격했는지 묻지 않습니다. 당신이 계속해서 합격하고 있다는 것을 증명할 수 있는지 묻습니다. 

EAA(Electronic Access Access Act)는 모바일 애플리케이션을 포함한 디지털 제품이 WCAG 2.2를 기술적 기준으로 삼아 장애가 있는 사용자를 위한 접근성 표준을 충족하도록 요구합니다. 하지만 규제 맥락에서의 준수는 단순히 애플리케이션이 출시 당일 검사를 통과했는지 여부에만 국한되지 않습니다. 조직이 소프트웨어 출시 과정에 접근성 검증을 일관되게, 그리고 장기적으로 포함시키고 있음을 입증할 수 있는지가 중요합니다. 

이는 "마감일 전에 검사를 완료했다"는 것과는 근본적으로 다른 기준입니다. 다른 모든 규정 준수 관련 테스트 영역에서와 마찬가지로, 어떤 감사자도 "한 번 통과했다"는 것을 지속적인 통제의 증거로 받아들이지 않습니다. 접근성 또한 예외는 아니며, 지난 1년간의 시행을 통해 감사, 구매 관련 질의응답, 그리고 점점 늘어나는 소송에 직면한 기업들은 이 점을 분명히 인지하게 되었습니다. 

미국에서 웹사이트 접근성 관련 소송이 사상 최고치를 기록했습니다. 2026년 상반기에 집계된 소송 건수는 역대 최고치를 경신했으며, 연간 소송 건수는 6,000건을 넘어설 것으로 예상됩니다. 이는 2025년보다 약 20% 증가한 수치이며, 2024년 대비 27% 증가한 수치이기도 합니다.UsableNet, 2026년 상반기 보고서).  

EU의 EAA 시행과 미국의 ADA 소송 사이에서 "결국엔 접근성 문제를 해결하겠지"라는 말은 엔지니어링이나 규정 준수 책임자가 할 수 있는 가장 값비싼 말 중 하나가 되었습니다. 

AI는 문제를 축소시키기는커녕 오히려 확대시켰다. 

여기서 타이밍이 중요합니다. 규제 시행은 소프트웨어 제공 속도가 빨라지는 바로 그 시점에 이루어졌습니다. 많은 기업에서 AI가 생성한 코드는 이제 전체 생산량의 40~50%를 차지하며, 그 비율은 계속 증가하고 있습니다.Digital.ai, 제4의 물결: AI가 코드를 작성하고 있다. 누가 그것을 테스트할까?)예전에는 며칠씩 걸리던 코딩 작업이 이제는 몇 시간 만에 완료됩니다. 

더 많은 코드를 더 빠르게 배포한다는 것은 매 스프린트마다 검증해야 할 접근성 문제가 더 많아진다는 것을 의미하며, AI가 작성한 코드라고 해서 단순히 빠르게 생성되었다는 이유만으로 접근성 검증을 통과하는 것은 아닙니다. 대체 텍스트 누락, 잘못된 포커스 순서, 레이블이 없는 폼 필드, 키보드 또는 스위치 탐색이 작동하지 않는 대화형 요소 등은 체계적인 검사가 이루어지지 않을 때 고속 개발 파이프라인을 통해 빠르게 확산되는 대표적인 회귀 오류 유형입니다. 

표준 릴리스 워크플로에 접근성 검증을 통합하지 않은 조직은 안정적인 상태를 유지하지 못하고 있습니다. 매 릴리스마다 규정 준수 부채가 누적되고 있으며, 그 부채는 1년 전보다 훨씬 빠르게 증가하고 있습니다. 

대부분의 팀이 여전히 목표에 미치지 못하는 이유는 무엇일까요? 

여기서 반복적으로 나타나는 격차는 바로 이것입니다. 스캔을 실행하는 것과 스캔이 실행되었음을 입증하는 것은 다르다는 점입니다. 접근성 결과가 빌드, 장치, 테스트 실행 정보와 분리된 별도의 대시보드에 저장되면, 팀은 기록이 아닌 문서만 보유하게 됩니다. 감사자가 묻는 질문, 즉 어떤 스캔이 어떤 빌드를 대상으로 어떤 장치에서 어떤 테스트의 일부로 실행되었는지에 대한 질문에는 재구성 작업이 아닌 직접적인 답변이 필요합니다. 

1년이 지난 지금, 문제를 해결할 수 있는 시간은 예전보다 훨씬 짧아졌습니다. 

EAA(Equal Access Act)는 시행 중이며, ADA(미국 장애인법) 관련 소송은 활발히 진행되고 있으며 그 규모는 점점 커지고 있습니다. WCAG 2.2는 모든 기업의 기준을 한 단계 높였습니다. 이러한 사실들은 이미 널리 알려져 있지만, 지난 1년간 이를 직접 경험하면서 한 가지 분명해진 점이 있습니다. 어려움을 겪는 기업들은 요구사항을 이해하지 못하는 것이 아니라, 지속적이고 감사 가능한 증거를 쉽게 검토하고 공유할 수 있도록 테스트 워크플로우를 구축하지 못한 기업들이라는 것입니다. 

이러한 격차를 해소하기 위해 완전히 새로운 접근성 프로그램을 만들 필요는 없습니다. 오히려 성숙한 조직들이 기능 테스트를 표준으로 여기고 모든 릴리스에 포함시켜 검증하는 것처럼 접근성 검증을 다루어야 합니다. 별도의 프로젝트로 진행하는 것이 아니라, 모든 릴리스에 이러한 검증 과정을 포함시켜야 합니다. 

여기는 Digital.ai 포함 사항: 자동 WCAG 스캐닝(가상화) 데케 업계에서 가장 널리 사용되는 접근성 엔진으로, 모든 결과는 해당 결과를 생성한 빌드, 장치 및 테스트와 연결되어 증거 격차를 해소합니다. 

어딘가에 우리 아버지 친구분이 당신 팀이 방금 출시한 제품을 써보려고 애쓰고 있을 겁니다. 규정 준수란 서류상의 기록이죠. 애초에 이런 것들을 만들 가치가 있는 이유가 바로 그분 때문입니다.