5.3 접근성

개요와 동기

접근성(흔히 “a11y”로 줄임)은 장애가 있는 사람이 지각하고, 이해하고, 탐색하고, 사용할 수 있는 소프트웨어를 만드는 실천입니다. 시각 장애가 있거나 저시력인 사람, 청각 장애가 있거나 난청인 사람, 운동 장애가 있는 사람, 인지 또는 학습 차이가 있는 사람, 부러진 팔, 강한 햇빛, 시끄러운 방 같은 일시적이거나 상황적인 제약에 직면한 사람을 포함합니다. 대략 다섯 명 중 한 명이 장애가 있고, 누구나 언젠가 접근 가능한 설계의 혜택을 봅니다. 이것은 틈새 배려가 아닙니다. 품질의 기준선입니다.

큰 팀에게 접근성은 개인의 선의에 맡기지 않고 시스템에 짜 넣어야 합니다. 많은 팀이 하나의 제품에 출하할 때, 라벨 없는 양식 필드, 색만으로 표시하는 상태 표시기, 모달의 키보드 트랩 같은 단 하나의 접근할 수 없는 컴포넌트가 장애가 있는 사용자를 여정 전체에서 가둘 수 있습니다. 접근성을 공유 컴포넌트, 디자인 토큰, 테스트 파이프라인, 완료의 정의에 짜 넣는 것이 규모에서 신뢰할 수 있게 만드는 유일한 방법입니다. 사후 보강은 비싸고 오류가 생기기 쉽습니다. 설계에 넣는 것은 싸고 오래갑니다.

정부에게 접근성은 법적 요건이자 시민의 의무이며, 있으면 좋은 것이 아닙니다. 공공 서비스는 대중 모두를 섬겨야 하고, 장애가 있는 시민은 흔히 대안 제공자가 없습니다. 정부 웹사이트에 접근할 수 없다면 다른 방법으로 급여, 면허, 투표를 얻을 수 없습니다. 전 세계의 법과 표준이 공공 기관에 접근성을 의무로 하고, 점점 민간 부문에도 그렇습니다. 이 장은 접근성을 동시에 세 가지로 다룹니다. 법적 의무, 윤리적 의무, 그리고 그저 좋은 디자인.

함께 보기: 5.2장(UI 디자인과 디자인 시스템), 5.6장(프런트엔드 엔지니어링), 5.1장(UX 기초).

핵심 원칙

접근성은 보안과 성능처럼 선택적 기능이 아니라 기준선 품질 속성입니다.
POUR 원칙: 인터페이스는 인지 가능하고(Perceivable), 조작 가능하고(Operable), 이해 가능하고(Understandable), 견고해야(Robust) 합니다.
시맨틱 HTML이 먼저입니다. ARIA는 진짜 간극을 메우는 데만 쓰고, 네이티브 요소의 대체물로 절대 쓰지 마십시오.
마우스로 쓸 수 있는 모든 것은 키보드만으로도 쓸 수 있어야 합니다.
색, 모양, 위치만으로 정보를 전달하지 마십시오.
자동화된 도구는 문제의 일부만 잡습니다. 수동 및 보조 기술 테스트가 필수입니다.
접근 가능한 설계는 모두에게 더 나은 설계입니다(장애가 있는 사람을 위해 만든 기능이 모든 사용자에게 득이 되는 “연석 경사로 효과”).
장애가 있는 사람을 위해서만이 아니라 그들과 함께 설계하고 테스트하십시오.

권장 사항

현재 표준을 겨냥해 WCAG에 맞춰 설계하고 만든다

웹 콘텐츠 접근성 지침(WCAG)은 국제적 기준입니다. WCAG 2.1과 2.2는 네 가지 POUR 원칙 아래 A, AA, AAA 적합성 수준의 테스트 가능한 성공 기준으로 조직되어 있습니다. 기준선으로 AA 수준을 겨냥하십시오. 대부분의 법이 참조하는 것입니다. WCAG 2.2는 포커스 가시성, 대상 크기, 인지 부하 줄이기에 대한 기준을 더합니다. WCAG 3.0은 다르게 구조화된 아직 개발 중인 신흥 후속입니다. 지켜보되 오늘은 2.2 AA에 맞춰 만드십시오. 지침을 천장이 아니라 바닥으로 다루십시오. 모든 기준을 통과한다고 진정으로 쓸 수 있는 경험이 보장되지는 않습니다.

시맨틱 HTML과 올바른 ARIA를 쓴다

네이티브 HTML 요소(버튼, 링크, 양식 컨트롤, 제목, 목록, 랜드마크)는 내장된 접근성 의미, 키보드 동작, 보조 기술 지원을 지닙니다. 먼저 그것을 쓰십시오. ARIA(Accessible Rich Internet Applications) 역할, 상태, 속성은 HTML이 표현할 수 없는 맞춤 위젯을 기술하는 데만 쓰고 ARIA 작성 실천을 따르십시오. ARIA의 첫 규칙은 단순합니다. 네이티브 요소로 된다면 ARIA를 쓰지 마십시오. 잘못된 ARIA는 없는 것보다 나쁩니다. 스크린 리더를 적극적으로 오도하기 때문입니다. 페이지에 논리적 제목 구조, 의미 있는 라벨, 이미지의 대체 텍스트, 미디어의 자막과 대본, 각 라벨과 컨트롤 사이의 프로그램적 연결을 주십시오.

키보드와 보조 기술 조작 가능성을 보장한다

모든 상호작용 요소는 논리적 순서로, 분명히 보이는 포커스 표시기와 함께 키보드만으로 닿고 조작할 수 있어야 합니다. 키보드 트랩을 피하십시오. 콘텐츠가 바뀔 때 포커스를 의도적으로 관리하십시오. 대화상자가 열리면 포커스를 옮기고, 닫히면 되돌리고, 동적 갱신은 라이브 리전으로 알리십시오. 데스크톱과 모바일의 스크린 리더, 화면 확대, 음성 제어, 스위치 접근을 포함한 실제 보조 기술로 테스트하십시오. 그리고 모션 줄이기와 대비 높이기 같은 사용자 선호를 존중하십시오.

자동화 도구, 수동 리뷰, 실제 사용자로 테스트한다

자동화된 접근성 스캐너는 가치가 있으며 모든 변경에서 파이프라인에서 돌아야 합니다. 그러나 연구들은 일관되게 그것이 실제 문제의 소수, 대략 3분의 1만 잡는다고 보여 줍니다. 나머지는 사람의 판단이 필요합니다. 키보드 훑기, 스크린 리더 테스트, 대비 점검, 콘텐츠가 실제로 이해되는지 묻기입니다. 무엇보다 중요하게, 사용성 테스트에 장애가 있는 사람을 포함하십시오. 출시 전 감사가 아니라 스토리마다 문제가 잡히도록 접근성 인수 기준을 완료의 정의에 짜 넣으십시오.

접근성을 영웅적이 아니라 조직적으로 만든다

컴포넌트가 기본으로 접근 가능하게 출하되도록 접근성을 디자인 시스템에 구우십시오. 디자이너, 엔지니어, 콘텐츠 작성자, 제품 관리자가 각자 무엇에 책임지는지 알도록 교육을 제공하십시오. 접근성 표준, 소유자나 전문 센터, 시정 프로세스를 확립하십시오. 접근성 성명서를 공개하고 사용자에게 장벽을 신고할 방법을 주십시오. 그리고 접근성을 고려해 조달하십시오. 벤더와 제3자 컴포넌트가 적합할 것과 증거(접근성 적합성 보고서 같은)를 제공할 것을 요구하십시오.

장단점

접근 방식	장점	단점
처음부터 접근성을 짜 넣기	가장 싸고, 오래가며, 모두에게 더 나음	선행 교육과 규율 필요
나중에 사후 보강 / 시정	노력을 미룸. 빠른 출시를 막지 않음	훨씬 비싸고, 취약하며, 그 사이 법적 노출
자동화 테스트만	빠르고 싸고 CI에서 회귀를 잡음	문제의 약 3분의 2를 놓침. 거짓된 확신
수동 + 보조 기술 테스트	실제 사용성 장벽을 잡음	더 느림. 숙련된 테스터와 기기 필요
장애가 있는 사용자와 테스트	실제 경험의 기본 진실	모집 노력과 비용. 존중하는 방식으로 해야 함

핵심 트레이드오프는 선행 규율 대 미룬 비용입니다. 짜 넣은 접근성은 싸고 모두의 품질을 개선하지만, 법적 압박 아래 사후 보강한 접근성은 비싸고, 불완전하고, 스트레스가 큽니다. 장기적으로는 “속도”에 맞서는 진짜 트레이드오프가 없습니다. 접근할 수 없는 소프트웨어는 단지 사용자의 5분의 1에게 동작하지 않습니다. 그것은 절감이 아니라 결함입니다.

팀과 논의할 질문

접근성 회귀가 깨진 테스트처럼 빌드를 실패시킵니까, 아니라면 왜입니까? 자동화된 스캐너는 문제의 약 3분의 1만 잡지만, 잡는 것(빠진 라벨, 대비 실패, 라벨 없는 컨트롤)은 CI에서 잡기 싸고 출시 전 감사에서 찾기 비쌉니다. 회귀를 빌드 실패로 다루는 것이 접근성을 영웅적 개인 노력에서 신뢰할 수 있는 시스템 속성으로 옮기며, 많은 팀이 하나의 제품에 출하할 때 동작하는 유일한 것입니다. 어떤 검사가 차단하고, 어떤 것이 권고이며, 누가 실패를 재정의할 수 있는지 결정하십시오. 현재 스캐너 결과와 완료의 정의를 회의에 가져오십시오. 접근성 기준이 스토리마다 완료의 정의에 쓰여 있지 않으면, 마감이 조여지는 순간 후순위로 밀릴 것입니다.
맞춤 위젯에 대한 규칙은 무엇이며, 출하 전에 누가 ARIA를 리뷰합니까? 네이티브 HTML 요소는 키보드 동작과 보조 기술 지원을 공짜로 가져오고, 잘못된 ARIA는 스크린 리더를 적극적으로 오도하므로 없는 것보다 나쁩니다. 시맨틱 HTML이 기본이며 모든 맞춤 위젯(맞춤 드롭다운, 날짜 선택기, 모달)은 병합 전에 ARIA 작성 실천에 따른 키보드 및 스크린 리더 훑기를 요구한다는 데 합의하십시오. 이는 많은 팀이 재사용하는 상호작용 컴포넌트에서 가장 중요합니다. 키보드 트랩이 있는 깨진 모달 하나가 장애가 있는 사용자를 여정 전체에서 가둘 수 있기 때문입니다. 맞춤 위젯 목록을 가져와 어느 것이 실제 스크린 리더로 테스트되었는지 물으십시오. 그렇지 않은 것은 공유 코드에 숨은 부채입니다.
접근성 오버레이에 대한 정책은 무엇이며, 그것이 진짜 해법이라고 믿는 사람이 있습니까? 오버레이는 사이트를 적합하게 만드는 한 줄 스크립트로 마케팅되며, 법적 압박이 오고 마감이 닥치면 유혹적입니다. 진정한 적합성을 주지 않고, 보조 기술 사용자의 경험을 악화시킬 수 있으며, 정부에서는 근본적인 법적 의무를 충족시키지 못한 채로 둡니다. 문제를 덮는 위젯을 사는 대신 시맨틱 마크업, 키보드 지원, 장애가 있는 사람과의 테스트에 투자하겠다고 명시적으로 결정하십시오. 오버레이 구독 비용을 가져와 컴포넌트와 파이프라인에 접근성을 한 번 짜 넣는 비용과 비교하십시오. 이를 일찍 구성하면 돈을 쓰고도 아무것도 고치지 못하는 허둥대는 조달 결정을 나중에 막습니다.
장애가 있는 사람이 우리 설계와 테스트의 일부입니까, 아니면 여전히 우리가 지어낸 상상의 사용자를 위해 설계하고 있습니까? 자동화된 스캐너와 전문가 감사조차 마크업이 적합한지 알려 줄 뿐이며, 시각 장애 사용자가 실제로 결제를 끝낼 수 있는지, 인지 장애가 있는 사람이 오류 메시지를 이해할 수 있는지는 알려 주지 않습니다. 장애가 있는 참가자를 참여시키는 것이 기본 진실의 유일한 원천이며 무엇을 만드는지를 바꾸지만, 공정하게 어떻게 모집하는지, 시간에 대해 어떻게 보상하는지, 한 참가자를 모든 장애의 대변인으로 취급하는 것을 어떻게 피하는지에 대한 실제 질문을 제기합니다. 현재 리서치 명단, 모집과 지급 방식, 지난해 연구 중 장애가 있는 참가자를 포함한 수에 대한 정직한 집계를 가져오십시오. 대규모 조직에서는 시각, 청각, 운동, 인지 필요를 덮고 공정한 보상이 있는 상시 패널이 이를 일회성 제스처에서 믿을 만한 입력으로 바꿉니다. 정부에서는 섬기는 대중을 참여시키는 것이 흔히 선택적 호의가 아니라 법적, 시민적 의무의 일부입니다.
제3자 컴포넌트를 사거나 내장할 때 접근성 증명을 요구하며, 누가 확인합니까? 대규모 제품에 출하되는 것의 상당수는 자체 작성이 아닙니다. 라이브러리의 날짜 선택기, iframe의 결제 위젯, 차트 패키지, SaaS 모듈 전체입니다. 내장된 접근할 수 없는 컴포넌트 하나가 자체 코드가 아무리 깨끗해도 여정 전체를 실패시킬 수 있고, 일단 연결되면 교체가 비쌉니다. 접근성이 조달 요구 사항이며, 벤더가 접근성 적합성 보고서(제품이 WCAG에 비해 어떤지 진술하는 VPAT 같은 문서)를 제공해야 하고, 누군가 기술적으로 그 주장을 철해 두는 대신 검증하도록 결정하십시오. 제3자 컴포넌트 목록을 가져와 어느 것이 최신이고 믿을 만한 적합성 증거를 지니는지 물으십시오. 기업과 정부 구매에서는 WCAG 2.2 AA 적합성과 시정권을 계약에 쓰십시오. 서명 전에 한 약속이 가동 후에 발견한 장벽보다 시행하기 훨씬 싸기 때문입니다.
목표 적합성 수준은 무엇이며, 누가 소유하고, 표준이 움직임에 따라 어떻게 최신으로 유지합니까? WCAG 2.2 AA가 오늘의 바닥이고 대부분의 법이 참조하지만, 2.2는 많은 팀이 채택하지 않은 기준을 더했고 WCAG 3.0은 다른 구조로 오고 있습니다. 지명된 소유자가 없으면 표준이 표류합니다. 다른 팀이 다른 버전을 겨냥하고, 아무도 간극을 추적하지 않으며, 적합성이 감사 사이에 조용히 썩습니다. 어느 정확한 버전과 수준에 맞춰 만들지, 누가 그것을 높일 권한이 있는지, 새 기준이 디자인 시스템과 완료의 정의에 어떻게 닿는지 결정하십시오. 현재 명시된 목표, 팀이 실제로 그것을 충족하는 곳의 증거, 건너뛴 2.2 기준을 채택하는 짧은 로드맵을 가져오십시오. 대규모 조직이나 공공 조직에서 접근성 소유자나 전문 센터, 공개된 접근성 성명서, 다음 표준 버전에 대한 문서화된 계획이 규제 기관이나 법원에 선의가 아니라 증거로 답하게 해 줍니다.

분야별 관점

스타트업. 속도가 여기서 여러분에게 유리합니다. 접근성은 코드베이스가 작을 때 가장 싸기 때문입니다. 첫 스프린트부터 CI에 자동화된 스캐너를, 풀 리퀘스트 체크리스트에 키보드 훑기를 추가하고, 시맨틱 HTML에 기대 키보드와 스크린 리더 지원을 공짜로 얻으십시오. 오버레이와 무거운 도구는 건너뛰십시오. 고객의 조달 팀이 판매 도중 적합성 보고서를 요청할 때, 허둥대는 대신 며칠 안에 답할 수 있다는 것이 수익입니다.

소기업. 접근성 전문가도 빠듯한 예산도 없으니 만들지 말고 사십시오. 이미 적합하고 그렇다고 밝히는 플랫폼, 테마, 컴포넌트 라이브러리를 고르고, 접근성 성명서를 게시하는 벤더를 선호하십시오. 무료 도구, 키보드 전용 점검, 대비 검사기, 모든 필드의 분명한 라벨 같은 고가치 기본기는 직접 처리하십시오. 고객을 가장 자주 배제하는 실패를 잡아내기 때문입니다. 잘못되었거나 쓸 수 없는 자동화 흐름을 잃은 고객으로 다루십시오. 소기업은 의지할 보조 채널을 제공하는 일이 드물기 때문입니다.

대기업. 규모에서 일은 접근성을 많은 팀에 걸친 시스템 속성으로 만드는 것입니다. 디자인 시스템에서 접근 가능한 컴포넌트를 기본으로 출하하고, CI에서 회귀를 관문 통제하고, 시정 프로세스와 디자이너, 엔지니어, 콘텐츠 작성자를 위한 교육이 있는 소유자나 전문 센터를 세우십시오. 적합성을 시간에 따른 지표로 추적하고, WCAG 적합성을 조달에 쓰고, 내장된 위젯 하나가 공유 여정을 조용히 실패시키지 못하도록 제3자 컴포넌트를 포트폴리오로 관리하십시오.

정부. 접근성은 법적 의무이자 시민의 의무입니다. 장애가 있는 시민은 흔히 급여, 면허, 투표의 대안 제공자가 없기 때문입니다. 관할이 인용하는 표준(예컨대 WCAG 2.2 AA에 매핑된 Section 508, EN 301 549, 유럽 접근성 법)에 맞춰 만들고, 장벽을 신고할 경로가 있는 접근성 성명서를 게시하고, 섬기는 장애가 있는 대중과 테스트하십시오. 오버레이를 진정한 적합성의 대체물로 거부하고, 벤더에게 믿을 만한 증거와 시정권을 계약에 제공하도록 요구하십시오.

사례

스타트업. 채용 도구를 만드는 세 명 규모의 스타트업은 나중에 고치는 것보다 접근 가능한 채로 있는 것이 더 싸다고 판단해, 바로 첫 스프린트부터 빌드에 접근성 스캐너를, 풀 리퀘스트 체크리스트에 빠른 키보드 훑기를 추가했습니다. 한 중견 고객의 조달 팀이 영업 주기 중 접근성 적합성 보고서를 요청했을 때, 스타트업은 이미 시맨틱 HTML을 쓰고, 모든 필드에 라벨을 붙이고, 어디서나 보이는 포커스를 갖추어 허둥대는 대신 며칠 안에 답했습니다. 그 준비가 같은 요건에서 경쟁사가 잃은 거래를 따냈습니다.

대기업. 한 대형 소매업체는 시각 장애 고객이 스크린 리더로 결제를 끝낼 수 없다는 이유로 집단 소송에 직면했습니다. 합의금과 법률 비용을 넘어, 회사는 법원이 감독하는 일정에 따라 시정해야 했습니다. 이후 접근성을 디자인 시스템과 CI 파이프라인에 다시 짜 넣고, 스크린 리더 테스트를 완료의 정의에 추가하고, 팀을 교육했습니다. 다시 만든 접근 가능한 결제는 모두의 전환을 개선하고 지원 접촉을 줄였습니다. 스크린 리더 사용자를 도운 수정(분명한 라벨, 오류 메시지, 논리적 순서)이 모든 사용자를 도왔습니다.

정부. 한 공공 급여 기관은 온라인 신청에 대해 WCAG 2.1 AA를 충족해야 할 법적 의무가 있었습니다. 시각 장애 및 저시력 사용자, 키보드 전용 사용자, 인지 장애가 있는 사용자와의 초기 테스트는 색만으로 표시한 “필수 필드” 표시기, 접근할 수 없는 날짜 선택기, 알림 없는 검증 오류가 사람들이 끝내지 못하게 막고 있음을 드러냈습니다. 시맨틱 마크업, 보이는 포커스, 라이브 리전 오류 알림, 쉬운 언어 도움말로 이를 고치자, 장애가 있는 시민이 처음으로 스스로 신청할 수 있게 되었습니다. 대면 도움에 대한 의존이 줄고 서비스 제공 비용이 낮아졌으며 법적 의무를 충족했습니다.

비즈니스 사례: 동기, ROI, TCO

비즈니스 사례는 시장 도달, 법적 위험, 서비스 제공 비용, 품질에 기댑니다. 장애가 있는 사람과 그 가족은 상당한 구매력을 통제하며, 그들을 배제하면 그것을 포기하게 됩니다. 접근 가능한 서비스는 비싼 보조 채널(전화와 대면 도움)의 필요를 줄이며, 이는 특히 정부에서 직접적인 운영 절감입니다. 그리고 접근성 개선(분명한 라벨, 키보드 지원, 읽기 쉬운 콘텐츠, 견고한 마크업)이 모두를 도우므로 대개 전체 완료와 만족을 높입니다.

TCO에서 도입 비용은 교육, 도구, 컴포넌트와 파이프라인에 접근성을 짜 넣는 것이며, 처음부터 하면 모두 소소합니다. 도입하지 않는 비용은 여러 방향에서 오는 심각한 것입니다. 법적 책임(소송, 합의, 법원 명령 시정, 규제 벌금), 마감 압박 아래 사후 보강하는 훨씬 높은 비용, 평판 손상, 배제된 사용자를 더 비싼 채널로 섬기는 지속적 비용입니다. 사후 보강은 대개 설계에 넣었을 때의 몇 배가 듭니다.

리더십을 설득하려면 적용되는 곳에서 법적 의무로 시작하십시오(정부에는 협상할 수 없고 점점 민간 부문에도 그렇습니다). 그다음 배제하고 있는 접근 가능 인구, 그 배제의 보조 채널 비용, 모든 사용자의 “연석 경사로” 이득을 정량화하십시오. 접근성을 자선이 아니라 위험 관리 더하기 품질로 위치시키십시오.

안티패턴과 함정

출시 전 체크박스로서의 접근성: 지속적 실천 대신 끝의 감사로, 비싼 막판 재작업을 보장.
“div 수프”: 일반 요소에 클릭 핸들러를 붙인 비시맨틱 마크업으로, 보조 기술에 보이지 않음.
ARIA 오용: 깨진 마크업에 ARIA를 덧붙여 평범한 마크업보다 스크린 리더를 더 오도하는 것.
색만으로 정보 전달: 색만으로 보이는 상태로, 색맹 사용자에게는 보이지 않음.
보이지 않는 포커스: 미관을 위해 포커스 윤곽선을 제거해 키보드 사용자를 고립시키는 것.
키보드 트랩: 포커스를 가두거나 잃는 모달과 위젯.
자동 스캔 안주: 스캐너를 통과하고 제품이 접근 가능하다고 가정하는 것.
접근성 오버레이: 진정한 적합성을 주지 못하고 경험을 악화시킬 수 있는 제3자 “한 줄 수정” 위젯.
장애가 있는 사용자를 리서치에서 배제: 실제 사용자와 테스트하는 대신 상상의 장애 사용자를 위해 설계하는 것.

성숙도 모델

1단계: 시작. 접근성 실천이 없습니다. 사용자가 불만을 제기하거나 소송이 도착해야만 문제가 발견되고, 대응은 반응적입니다. 마크업은 비시맨틱하고 테스트되지 않았으며 아무도 문제를 소유하지 않습니다.

2단계: 발전. 인식이 있고 일부 팀이 행동합니다. 여기 빌드의 자동화된 스캐너, 저기 키보드 훑기, 큰 릴리스 전의 출시 전 감사입니다. 실천은 기본적이고 팀마다 일관되지 않으며, 접근성은 여전히 후반 단계의 체크리스트이고 일정 압박 아래 자주 후순위로 밀립니다.

3단계: 표준화. WCAG 2.2 AA가 조직 전체에서 시행되는 문서화된 표준입니다. 접근성이 디자인 시스템에 구워져 컴포넌트가 기본으로 접근 가능하게 출하되고, 자동 및 수동으로 테스트되며, 완료의 정의에 쓰여 있습니다. 팀이 교육받고, 소유자나 전문 센터가 있으며, 시정 프로세스가 정의되어 있습니다.

4단계: 관리. 접근성이 기준선에 대한 데이터로 측정되고 통제됩니다. 조직은 적합성 지표를 시간에 따라 추적하고(스캐너 통과율, 심각도별 열린 장벽 수, 핵심 여정의 스크린 리더 테스트 커버리지, 시정 시간), 팀별로 대시보드에 보고하며, 회귀를 권고 경고가 아니라 빌드 실패로 다룹니다. 목표가 기준선에 대해 설정되고 진행이 검토되어, 뒤처지는 팀이 감사가 찾기 전에 보입니다.

5단계: 오케스트레이션. 접근성이 조직 전체에서 지속적으로 개선되고 통합됩니다. 장애가 있는 사람이 정기적으로 리서치와 테스트의 일부이고, 접근성이 조달, 디자인 토큰, CI에 내장되어 있습니다. 조직은 표준이 움직임에 따라 적응하며(새 WCAG 기준을 채택하고 WCAG 3.0을 준비), 벤더와 파트너에 영향을 미쳐 공급망 전체가 적합하게 합니다.

논의를 위한 아이디어

마감이 조여질 때 접근성이 후순위로 밀리지 않게 하려면 어떻게 합니까?
위험 프로필에 맞는 자동화, 수동, 사용자 테스트의 알맞은 혼합은 무엇입니까?
접근성 적합성을 벤더 계약과 조달에 어떻게 써야 합니까?
WCAG 적합성과 장애가 있는 사람의 진정한 사용성 사이의 간극을 어떻게 다룹니까?
오늘은 2.2에 맞춰 만들면서 팀은 WCAG 3.0을 어떻게 준비해야 합니까?
장애가 있는 연구 참가자를 공정하고 존중하는 방식으로 어떻게 모집하고 보상합니까?

핵심 요점

접근성은 기준선 품질 속성이며 정부에게는 법적 요건입니다.
WCAG 2.2 AA를 바닥으로 설계하고 POUR 원칙을 멘탈 모델로 쓰십시오.
시맨틱 HTML이 먼저입니다. ARIA는 진짜 간극에만, 올바르게 쓰십시오.
자동화 도구는 문제의 약 3분의 1을 잡습니다. 수동 및 보조 기술 테스트가 필수입니다.
장애가 있는 사람을 위해서만이 아니라 그들과 함께 테스트하십시오.
접근성을 짜 넣는 것은 싸고 오래가며, 사후 보강은 비싸고 취약합니다.
접근 가능한 설계는 모두에게 더 나은 설계입니다. 연석 경사로 효과는 실재합니다.

참고 문헌과 더 읽을거리

W3C, Web Content Accessibility Guidelines (WCAG) 2.2 and supporting Understanding/Techniques documents
W3C, WAI-ARIA Authoring Practices Guide
W3C Web Accessibility Initiative (WAI), introductory and tutorial materials
Laura Kalbag, Accessibility for Everyone
Sarah Horton and Whitney Quesenbery, A Web for Everyone
Regine Gilbert, Inclusive Design for a Digital World
U.S. Section 508 standards and Section508.gov guidance
European standard EN 301 549 and the European Accessibility Act
Government accessibility guidance (e.g., UK GDS accessibility manual)
WebAIM, research and articles including the annual accessibility analyses