이번 주 접근성 소식은 일정이 늦춰져도 실행은 늦출 수 없다는 메시지로 모입니다. WordPress 접근성 팀은 7.0 릴리스와 테마 접근성 요건 정비를 이어갔고, Deque는 HHS Section 504 기한 연장이 접근성 의무의 유예가 아니라는 점을 다시 짚었습니다.
실무 측면에서는 브라우저 기반 접근성 테스트의 중요성이 커지고 있습니다. JavaScript, CSS, 서드파티 위젯이 런타임에 접근성 트리를 바꾸는 환경에서는 정적 HTML 검사만으로 사용자 경험을 충분히 검증하기 어렵습니다.
국내외 뉴스
WordPress 접근성 팀, 7.0 릴리스와 문서 정비 진행 상황 공유
WordPress 접근성 팀은 5월 7일 회의 노트를 공개하며 WordPress 7.0 릴리스 준비와 접근성 문서 정비 현황을 공유했습니다. 특히 Gutenberg의 시각적 수정 관련 접근성 이슈가 7.0 릴리스의 주요 점검 대상으로 언급됐고, 일부 핵심 이슈는 7.0에 포함될 가능성이 있다고 설명했습니다.
또한 accessibility-ready 테마 요구사항이 갱신됐으며, 접근성 테스트 문서와 내부 리소스를 보강하는 작업도 진행 중입니다. WordPress 생태계처럼 테마·플러그인·블록이 얽힌 플랫폼에서는 접근성 기준을 문서화하고 검토 프로세스에 넣는 일이 제품 품질과 직결됩니다.
출처: Make WordPress Accessible ↗ (2026.05.11)
표준 업데이트 (WCAG, WAI-ARIA 등)
이번 주에는 W3C WCAG, WAI-ARIA, ARIA APG의 주요 신규 표준 업데이트는 확인되지 않았습니다. 다만 WordPress 접근성 팀이 최근 갱신한 accessibility-ready 요구사항은 WCAG 기대치에 더 가깝게 맞추는 방향으로 정리됐고, 테마 검토 기준에 reflow, resize, text spacing, hover/focus 콘텐츠, 접근성 선언 같은 항목을 더 명확히 반영했습니다.
표준 자체의 변경은 아니지만, 생태계별 검토 기준이 WCAG 2.1·2.2 관점을 더 구체적인 테스트 절차로 번역하고 있다는 점은 실무자에게 중요합니다. 디자인 시스템이나 CMS 테마를 운영하는 팀이라면 “기준 문서”와 “검증 절차”를 분리하지 말고 함께 관리하는 편이 좋습니다.
출처: Make WordPress Accessible ↗ (2026.05.06)
도구 & 기술
브라우저 기반 접근성 테스트, 런타임 접근성 트리 검증 필요성 강조
WebYes는 브라우저 기반 접근성 검사 필요성을 정리하며, 현대 웹 페이지의 접근성 문제가 소스 HTML만으로는 충분히 드러나지 않는다고 설명했습니다. CSS 변수, JavaScript 상태 변경, 서드파티 스크립트가 모두 적용된 뒤 브라우저가 만든 접근성 트리를 기준으로 검사해야 실제 사용자가 만나는 문제에 가까워집니다.
특히 WebAIM Million 2026에서 홈 페이지의 평균 접근성 오류가 증가했고, ARIA 코드가 더 많이 쓰이지만 잘못 쓰이는 경우도 늘었다는 점을 근거로 들었습니다. 프런트엔드 팀은 lint나 정적 검사에 더해 Playwright, axe, 브라우저 확장, 스크린 리더 검증을 조합해 런타임 상태를 확인해야 합니다.
출처: WebYes ↗ (2026.05.12)
법률 & 정책
Deque, HHS Section 504 기한 연장은 “요건 완화”가 아니라고 설명
Deque는 HHS가 Section 504 웹·모바일 접근성 준수 기한을 1년 연장한 이후, 무엇이 바뀌었고 무엇이 그대로인지 정리했습니다. 15명 이상 수급 기관은 2027년 5월 11일, 15명 미만 기관은 2028년 5월 10일까지 WCAG 2.1 A/AA 기준을 충족해야 하지만, 디지털 접근성 제공 의무 자체가 사라진 것은 아닙니다.
핵심은 “일정 연장”과 “책임 유예”를 구분하는 것입니다. Deque는 기관이 지금도 접근 불가능한 디지털 경험에 대해 민원, 조사, 소송 리스크를 가질 수 있으며, 새 기한까지 명확한 개선 로드맵과 진행 증거를 갖춰야 한다고 설명했습니다.
출처: Deque ↗ (2026.05.13)
실무 사례 & 가이드
WordPress 테마 접근성 검토, 테스트 절차와 pass/fail 기준을 구체화
WordPress의 갱신된 accessibility-ready 요구사항은 각 항목을 원칙, 테스트 절차, WCAG 참고 자료로 나눠 설명합니다. 테스트에 필요한 도구와 단계별 pass/fail 기준을 문서화해, 접근성 경험이 많지 않은 검토자도 더 일관된 피드백을 제공할 수 있게 하는 방향입니다.
이 접근은 WordPress 테마에만 해당하지 않습니다. 디자인 시스템 컴포넌트나 사내 UI 라이브러리도 “이 컴포넌트는 접근 가능해야 한다”에서 멈추지 말고, 어떤 도구로 어떤 상태를 어떤 기준에 따라 확인할지까지 문서화해야 품질이 반복됩니다.
출처: Make WordPress Accessible ↗ (2026.05.06)
마무리
이번 주에는 완전히 새로운 표준 발표보다, 이미 정해진 기준을 실제 제품 운영에 녹이는 흐름이 더 뚜렷했습니다. WordPress는 접근성 기준을 테마 검토와 문서화로 옮기고 있고, Deque는 법적 기한이 늦춰져도 접근성 개선은 지금 진행해야 한다고 강조합니다.
개발팀이라면 이번 주에는 두 가지를 점검해볼 만합니다. 첫째, 자동화 접근성 검사가 실제 브라우저 런타임 상태를 반영하는지 확인합니다. 둘째, 컴포넌트·테마·페이지별 접근성 검증 기준을 pass/fail 형태로 문서화해 누구나 같은 기준으로 리뷰할 수 있게 만듭니다.