변하는 제품에는 계속 확인하는 과정이 필요하다
소프트웨어 엔지니어 미하일 프로스미츠키는 스매싱 매거진 기고에서 접근성을 신뢰성과 보안처럼 지속적으로 다룰 운영 역량으로 보자고 제안했다. 글은 레벨 액세스의 지원을 받아 작성됐다. 한 번의 감사가 기록과 문제 발견에 쓰이더라도 이후 기능과 탐색 구조가 바뀌면 그 결과만으로 현재 상태를 설명하기 어렵다는 논지다.
저자는 디자인 시스템에서 출발해 완료 기준과 코드 검토에 접근성 요구를 넣고, 키보드 탐색과 포커스 관리도 일반적인 개발 관심사로 다루라고 권한다. AI 생성 코드에도 의미 있는 HTML과 상태·이름 정보를 요구하자는 제안이다. 이는 생성 방식과 관계없이 최종 동작을 검증하는 절차가 필요하다는 운영 관점으로 읽을 수 있다.
공식 조사 수치와 자동 검사의 한계
WebAIM의 2026년 보고서는 2월에 백만 개 홈페이지를 WAVE로 분석해 95.9%에서 자동으로 발견 가능한 WCAG 실패를 찾았다고 밝혔다. 평균 오류 수는 페이지당 56.1개였다. 분석 대상은 각 사이트의 모든 화면이 아니라 홈페이지이며, 자동 검사로 발견할 수 없는 문제는 이 결과에 포함되지 않는다.
공식 보고서의 페이지 요소 수 증가율은 전년 대비 14.3%다. 원출처 기고가 설명한 20% 이상 증가와는 차이가 있다. 또한 이 조사만으로 AI 생성 코드가 증가의 원인이라고 확정할 수 없다. WebAIM은 오류가 발견되지 않아도 페이지의 접근성이나 기준 충족을 뜻하지 않는다고 명시한다.
공통 컴포넌트는 서비스 검증의 출발점이다
GOV.UK 디자인 시스템 팀은 접근성 개선을 지속적이고 반복적인 과정으로 설명한다. 접근성을 고려한 스타일과 컴포넌트, 패턴을 사용하더라도 서비스에는 추가 연구와 설계, 개발, 테스트가 필요하다고 밝힌다. 구성 요소의 사용 여부와 전체 과업의 사용 가능성을 구별하는 공식 운영 설명이다.
따라서 공통 버튼을 사용했다는 이유만으로 결제나 가입 절차가 완성됐다고 볼 수는 없다. 구성 요소 자체의 이름과 동작 외에도 오류 뒤의 안내, 화면 전환 시 포커스, 단계 간 정보 연결을 살펴야 한다. 기고의 디자인 시스템 중심 접근은 이런 서비스 단위 검증과 함께 적용할 때 의미가 있다.
검사 결과를 실제 수정의 책임으로 연결하다
자동 검사를 배포 과정에 넣으면 같은 종류의 문제가 되풀이되는지 볼 수 있다. 그러나 오류 숫자를 표시하는 대시보드만으로 수정은 일어나지 않는다. 담당 팀과 영향을 받는 과업, 완료를 확인할 조건을 연결해야 한다. 같은 오류라도 첫 화면의 장식과 제출 버튼 주변에서 나타나는 문제는 사용자에게 미치는 영향이 다를 수 있다.
컴포넌트를 고치는 경우에는 어느 화면에서 재사용되는지도 함께 확인할 필요가 있다. 한 곳의 수정이 여러 경로를 개선할 수 있는 대신, 변경이 새 포커스 문제나 상태 표현의 혼란을 만들 수도 있다. 대표 사용 흐름을 골라 회귀를 확인하면 재사용의 효과를 유지하면서 실제 동작을 살필 수 있다.
생성 속도와 사용 가능성을 같은 완료 기준 안에
AI로 빠르게 만든 화면도 사용자가 결과에 도달할 수 있어야 완료된다. 예를 들어 오류가 생겼다는 문구만 추가할 것이 아니라 무엇을 고쳐야 하는지 읽을 수 있고 해당 입력으로 돌아갈 수 있는지를 확인할 수 있다. 픽셀의 유사성과 과업 수행의 동등함을 나누어 보는 것이 코드 검토와 실제 이용 점검을 연결한다.
이때 사용자 연구는 스캐너의 통과 결과를 대체하는 점수 경쟁이 아니다. 도구가 표시하지 못한 어려움을 발견하고 예상한 동작이 실제로 이해되는지 확인하는 역할을 한다. 보조기술과 키보드 등 서로 다른 이용 방식에서 핵심 과업을 수행하는 과정을 살펴야 공통 컴포넌트의 한계와 서비스 설계의 문제가 구분된다.
운영 과정에는 이전에 수정한 문제가 다음 변경에서 다시 나타나는지 확인하는 일도 포함된다. 감사 기록을 날짜가 붙은 보고서로만 보관하기보다 수정 근거와 반복 점검의 입력으로 연결하면 유용하다. 접근성을 담당자 한 명의 기억에 의존시키지 않고 개발과 지원의 업무에 남기는 것이 이 기고가 제안하는 실질적인 전환이다.
출처
Smashing Magazine의 원출처와 본문에 표시한 참고자료를 바탕으로 한국어로 재구성했습니다. ‘ARCH.B 분석’은 자료를 읽고 덧붙인 편집 해석입니다.
Why Accessibility Is An Operational Capability, Not A Feature (새 창)