이번 주 접근성 소식은 GAAD(Global Accessibility Awareness Day)를 중심으로 모였습니다. Apple과 GitHub는 AI와 개발자 생태계 관점의 접근성 전략을 공개했고, 국내에서는 배달의민족이 디지털 취약계층과 외국인 이용자를 함께 고려한 쉬운 안내서를 확장했습니다.
한편 법률·정책 영역에서는 EU와 캐나다의 접근성 의무가 더 구체적인 실행 일정으로 다가오고 있습니다. 접근성은 더 이상 별도 캠페인이나 체크리스트가 아니라, 제품 개발·조달·운영 전반에 남는 증거와 프로세스의 문제가 되고 있습니다.
국내외 뉴스
Apple, Apple Intelligence 기반 접근성 기능 업데이트 공개
Apple은 5월 19일 VoiceOver, Magnifier, Voice Control, Accessibility Reader에 Apple Intelligence를 적용한 접근성 업데이트를 공개했습니다. VoiceOver와 Magnifier는 이미지와 화면 내용을 더 자세히 설명하고, Voice Control은 화면 요소를 자연어로 지시해 조작하는 방향으로 확장됩니다.
또한 자막이 없는 영상에 온디바이스 generated subtitles를 제공하고, Apple Vision Pro로 호환 전동 휠체어를 눈으로 제어하는 기능도 예고했습니다. AI 접근성 기능이 단순 보조 설명을 넘어 탐색, 입력, 미디어 접근, 이동 보조까지 넓어지고 있다는 점이 중요합니다.
출처: Apple Newsroom ↗ (2026.05.19)
GitHub, 오픈소스와 개발자 경험 중심의 접근성 전략 공유
GitHub는 GAAD를 맞아 접근성 프로그램 5년을 돌아보고, 앞으로의 전략을 공개했습니다. 핵심 방향은 내부 제품 접근성 개선을 넘어 오픈소스 생태계, 장애가 있는 개발자, AI 기반 개발 도구, 엔터프라이즈 고객 자문까지 확장하는 것입니다.
특히 Open Source Assistive Technology Hackathon, 접근성 모범 사례 가이드, pull request 파일 변경 화면의 키보드 탐색·landmark·줄 간격 개선 등이 함께 소개됐습니다. 개발 플랫폼 자체의 접근성이 좋아지면, 장애가 있는 개발자의 참여뿐 아니라 오픈소스 프로젝트의 접근성 품질도 함께 올라갈 수 있습니다.
출처: The GitHub Blog ↗ (2026.05.21)
배달의민족, ‘쉬운 배달앱 사용법’ 영문판 배포
우아한형제들은 세계 접근성 인식의 날을 맞아 배달의민족 ‘쉬운 배달앱 사용법’ 영문판을 제작·배포했습니다. 이 안내서는 고령층, 발달장애인 등 디지털 기기 사용이 어려운 이용자를 위해 그림과 쉬운 표현 중심으로 구성된 자료입니다.
이번 영문판은 배민 앱의 다국어 기능 확대와 외국인 이용자 증가를 반영한 조치입니다. 접근성을 장애 여부만이 아니라 언어, 디지털 숙련도, 문화적 맥락까지 포함하는 사용성 문제로 넓게 본 사례로 볼 수 있습니다.
출처: ZDNet Korea ↗ (2026.05.21)
표준 업데이트 (WCAG, WAI-ARIA 등)
이번 주에는 W3C WCAG, WAI-ARIA, ARIA APG의 주요 신규 표준 업데이트는 확인되지 않았습니다. 대신 실무 문서와 컴플라이언스 가이드에서 WCAG 2.2 AA, EN 301 549, VPAT 2.5처럼 이미 정해진 기준을 어떻게 적용하고 증빙할지에 대한 논의가 이어졌습니다.
표준이 바뀌지 않는 주에도 할 일은 분명합니다. 팀 내부에서 사용하는 접근성 기준이 WCAG 2.2 AA까지 반영되어 있는지, 조달·감사·고객 요청에 대응할 수 있는 ACR 또는 VPAT 형태의 증거가 준비되어 있는지 점검해야 합니다.
출처: W3C WCAG 2.2 ↗ (2026.05.24 확인)
도구 & 기술
GitHub, 개발 워크플로우 안으로 접근성 도구를 확장
GitHub의 접근성 전략은 제품 UI 개선뿐 아니라 개발 워크플로우 자체를 접근성 친화적으로 바꾸는 데 초점을 둡니다. 공개 내용에는 pull request 경험 개선, Primer Design System 기반의 접근성 내재화, 오픈소스 프로젝트가 참고할 접근성 모범 사례 문서가 포함됐습니다.
개발팀 입장에서는 접근성 도구를 별도 검사 단계로만 두지 않고, 코드 리뷰·디자인 시스템·문서화·오픈소스 기여 흐름 안에 넣어야 한다는 신호입니다. 접근성 부채를 나중에 모아 고치는 방식보다, PR 단위에서 발견하고 설명하고 고치는 흐름이 더 지속 가능합니다.
출처: The GitHub Blog ↗ (2026.05.21)
Forbes Accessibility 200, 접근성 혁신에서 AI 활용 흐름 강조
Deque는 2026 Forbes Accessibility 200 목록에 2년 연속 선정됐다고 밝히며, 올해 목록에서 AI와 자동화가 접근성 혁신의 핵심 흐름으로 다뤄졌다고 소개했습니다. Forbes 목록은 기업과 비영리 조직을 포함해 전 세계 접근성 영향력을 조명합니다.
AI는 이미지 설명, 자막 생성, 코드 보조, 접근성 검사 자동화처럼 접근성 개선 속도를 높일 수 있습니다. 다만 자동화가 모든 사용자 경험을 보장하지는 않으므로, 실제 장애 사용자 피드백과 수동 테스트를 함께 운영하는 방식이 필요합니다.
출처: Deque ↗ (2026.05.20)
법률 & 정책
캐나다 Accessible Canada Act 진행 보고 기한 임박
Deque는 캐나다 연방 규제 대상 조직의 Accessible Canada Act(ACA) 연례 진행 보고서 제출 기한이 2026년 6월 1일로 다가오고 있다고 정리했습니다. 진행 보고서는 식별한 장벽, 받은 피드백, 수행한 조치, 측정 가능한 진전을 공개적으로 보여줘야 합니다.
이는 접근성 활동이 단발성 감사 보고서로 끝나기 어렵다는 뜻입니다. 조직은 디자인, 개발, 조달, 콘텐츠, 테스트, 거버넌스 전반에서 어떤 개선을 했고 어떤 책임 체계를 갖췄는지 설명할 수 있어야 합니다.
출처: Deque ↗ (2026.05.21)
EU Accessibility Act, 스타트업과 디지털 제품에도 실질 영향 확대
University of Bonn은 창업자와 스타트업이 European Accessibility Act(EAA)를 어떻게 이해해야 하는지 정리했습니다. EAA는 웹사이트, 모바일 앱, e-commerce, 스트리밍, 디지털 커뮤니케이션, e-book 등 다양한 디지털 서비스에 접근성 요구사항을 적용합니다.
특히 EU 시장에 제품이나 서비스를 제공하는 팀이라면 규모가 작더라도 예외 범위와 제품 유형을 따져봐야 합니다. 새 제품은 초기 설계부터 POUR 원칙과 WCAG 기준을 고려해야 하며, 기존 제품도 전환 기한을 기다리기보다 접근성 부채를 단계적으로 줄이는 계획이 필요합니다.
출처: University of Bonn ↗ (2026.05.18)
실무 사례 & 가이드
ARIA 라벨 가이드, “ARIA보다 native HTML 먼저”를 재강조
Web Accessibility Checker는 ARIA label, aria-labelledby, aria-describedby의 차이와 오용 사례를 정리한 개발자 가이드를 공개했습니다. 핵심은 접근 가능한 이름을 만들기 위해 무조건 aria-label을 붙이는 것이 아니라, 보이는 라벨이 있으면 aria-labelledby를 쓰고 가능한 경우 native HTML을 우선해야 한다는 점입니다.
ARIA는 접근성 트리에 영향을 주지만 화면에는 보이지 않습니다. 따라서 잘못 쓰면 시각 사용자와 스크린 리더 사용자가 서로 다른 인터페이스를 경험할 수 있습니다. 컴포넌트 라이브러리에서는 아이콘 버튼, 입력 필드, 커스텀 컨트롤의 이름 계산 방식을 테스트 케이스로 고정해두는 편이 좋습니다.
출처: Web Accessibility Checker ↗ (2026.05.21)
VPAT 작성 가이드, 접근성 증빙은 “정직한 부분 지원 설명”이 핵심
AccessProof는 VPAT(Voluntary Product Accessibility Template)와 ACR(Accessibility Conformance Report) 작성 방법을 정리했습니다. VPAT은 인증서가 아니라 제품이 Section 508, WCAG, EN 301 549 등 기준을 어떻게 충족하는지 선언하는 조달 표준 문서입니다.
특히 Partially Supports 항목에는 어떤 한계가 있고 언제 개선할지 명확히 적어야 한다고 강조합니다. 접근성 문서는 모든 항목을 무리하게 “Supports”로 채우는 것보다, 검증 증거와 개선 계획을 함께 남기는 쪽이 신뢰와 법적 리스크 관리에 더 안전합니다.
출처: AccessProof ↗ (2026.05.19)
마무리
이번 주의 핵심은 접근성이 기능, 도구, 법적 증빙으로 동시에 확장되고 있다는 점입니다. Apple은 AI로 사용자 보조 경험을 넓히고, GitHub는 개발 워크플로우와 오픈소스 생태계에 접근성을 넣고 있으며, EU·캐나다 사례는 접근성 활동의 결과를 문서로 증명하라고 요구합니다.
프런트엔드 팀이라면 이번 주에는 세 가지를 점검해볼 만합니다. 첫째, 아이콘 버튼과 커스텀 컨트롤의 accessible name 테스트를 추가합니다. 둘째, PR·디자인 시스템 문서 안에 접근성 체크 기준을 넣습니다. 셋째, 외부 고객이나 조달 요청에 대비해 VPAT/ACR에 필요한 증거를 평소 테스트 산출물로 남깁니다.