이번 주 접근성 소식은 일정이 늦춰져도 실행은 늦출 수 없다는 메시지로 모입니다. 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 상태 변경, 서드파티 스크립트가 모두 적용된 뒤 브라우저가 만든 접근성 트리를 기준으로 검사해야 실제 사용자가 만나는 문제에 가까워집니다.
WebYes는 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는 새 기한까지 명확한 개선 로드맵과 진행 증거를 갖춰야 한다고 설명했습니다.
출처: Deque ↗ (2026.05.13)
실무 사례 & 가이드
WordPress 테마 접근성 검토, 테스트 절차와 pass/fail 기준을 구체화
WordPress의 갱신된 accessibility-ready 요구사항은 각 항목을 원칙, 테스트 절차, WCAG 참고 자료로 나눠 설명합니다. 테스트에 필요한 도구와 단계별 pass/fail 기준을 문서화해, 접근성 경험이 많지 않은 검토자도 일관된 피드백을 줄 수 있게 했습니다.
이 방식은 디자인 시스템 컴포넌트나 사내 UI 라이브러리에도 적용됩니다. “이 컴포넌트는 접근 가능해야 한다”에서 멈추지 않습니다. 어떤 도구로 어떤 상태를 어떤 기준에 따라 확인할지까지 문서화해야 매번 같은 품질이 나옵니다.
출처: Make WordPress Accessible ↗ (2026.05.06)
마무리
이번 주에는 새로운 표준 발표 대신, 이미 정해진 기준을 실제 제품 운영에 적용하는 소식이 많았습니다. WordPress는 접근성 기준을 테마 검토와 문서화로 옮기고 있습니다. Deque는 법적 기한이 늦춰져도 접근성 개선은 지금 진행해야 한다고 설명합니다.
개발팀이라면 이번 주에는 두 가지를 점검해볼 만합니다. 첫째, 자동화 접근성 검사가 실제 브라우저 런타임 상태를 반영하는지 확인합니다. 둘째, 컴포넌트·테마·페이지별 접근성 검증 기준을 pass/fail 형태로 문서화해 누구나 같은 기준으로 리뷰할 수 있게 만듭니다.