ARIA, 함부로 쓰면 웹 접근성을 해칩니다!

논의에서는 APG가 '최신 LLM 에이전트'를 통해 코드를 생성하는 방식이 아니라, ARIA 명세(ARIA Specification)의 이론적 동작 방식을 보여주기 위한 가이드임을 강조합니다. 따라서 실제 웹사이트 구축 시 '최적의 접근성 패턴(Most Accessible Patterns)'을 제시하는 것이 아니라, ARIA 기능 시연(ARIA Capability Demonstration)에 초점을 맞추고 있음을 지적합니다. 이는 개발자들이 APG를 '모범 사례(Best Practice)'로 오해하는 주요 원인으로 작용합니다.

커뮤니티에서는 네이티브 HTML 요소(Native HTML Elements)가 이미 내장된 시맨틱(Semantic)과 동작 방식을 제공하므로, ARIA를 추가하여 기존 요소를 재정의하는 것보다 우선적으로 사용해야 한다고 주장합니다. 예를 들어, `<button>` 요소 대신 `<div>`에 `role="button"`을 부여하는 것은 불필요한 복잡성(Unnecessary Complexity)을 야기하며, 브라우저 및 보조 기술 지원의 불확실성을 높인다고 지적합니다. 이는 웹 표준 준수(Web Standards Compliance)의 기본 원칙과도 일맥상통합니다.

글에서는 최신 LLM 에이전트가 APG를 기반으로 코드를 생성하는 것에 대한 깊은 우려를 표합니다. APG 자체가 '최적의 접근성 패턴'이 아닌 이론적 시연임을 고려할 때, LLM이 생성한 코드는 실제 환경에서의 접근성 오류(Accessibility Errors in Real-world Environments)를 증가시킬 수 있습니다. 이는 '더 많은 ARIA 속성이 감지될수록 접근성 오류가 증가했다'는 WebAIM Million 보고서의 결과와도 일치하며, 자동화된 코드 생성(Automated Code Generation)의 잠재적 위험성을 시사합니다.

논의에 따르면, ARIA의 광범위한 오용은 오히려 웹 접근성을 저해하는 요인이 됩니다. 특히 보조 기술(Assistive Technologies), 스크린 리더 외의 다른 기술에 대한 이해 부족은 ARIA를 잘못 적용하게 만드는 원인으로 지목됩니다. 결과적으로, ARIA 사용이 증가할수록 감지되는 접근성 오류(Detected Accessibility Errors)가 늘어난다는 WebAIM의 연구 결과는 ARIA 적용 시 신중한 접근과 깊이 있는 이해가 필수적임을 강조합니다.