The Potentially Dangerous Non-Accessibility Of Cookie Notices

쿠키에 대한 귀하의 입장이 무엇이든, 데이터 보호, 웹 광고, 쿠키 설정, EU의 일반 데이터 보호 규정(GDPR) 및 개인 정보 기본 설정에 대한 귀하의 관점이 무엇이든, 쿠키 동의 위젯(또는 "쿠키 배너")은 오늘날 웹의 현실. 이러한 이유로 이러한 배너가 얼마나 접근 가능하고 사용 가능한지 조사할 가치가 있습니다. 좋든 나쁘든 오늘날 대다수 웹 사이트의 구성 요소가 되었습니다. 더욱이 쿠키 배너는 사용자가 가장 먼저 접하게 되는 경우가 많습니다. 물론 일단 구현되면 웹페이지의 모든 사이트의 일부가 됩니다. 경우에 따라 쿠키 배너는 페이지의 기능 세트 또는 페이지의 광고 때문에 기술적으로 필요합니다. 더 자주 쿠키 배너는 프런트 엔드 팀에서 구축하지 않고 UserCentrics 또는 기타와 같은 기성 솔루션입니다. 공지가 웹사이트 헤더 상단에 있는 예시적인 쿠키 배너 그림 ( 큰 미리보기 ) 쿠키 배너가 접근성과 관련하여 특별한 주의를 기울여야 하는 이유를 설명하기 전에 현재 웹 접근성의 표준인 WCAG(Web Content Accessibility Guidelines) 버전 2.1이 어떻게 작동하는지 간단히 설명하겠습니다. WCAG는 원칙, 지침 및 성공 기준으로 구성됩니다. 후자는 웹 페이지를 확인하기 위한 테스트 가능한 단계입니다. 예를 들어: "문서의 기본 언어가 설정되어 있습니까?" "이 텍스트가 아닌 콘텐츠에 적합한 대체 텍스트가 있습니까?" "키보드(또는 키보드 누름을 에뮬레이트하는 다른 기술)로 웹 존재를 사용할 때 내 초점이 어디에 있는지 인지할 수 있습니까?" 이것이 "예 또는 아니오" 질문이라는 것을 눈치채셨을 것입니다. 따라서 이는 주어진 성공 기준의 최종 판정이 "통과" 또는 "불합격"임을 의미합니다. 또한 W3C(웹 관리 기관)에서 정의한 WCAG 준수는 전체 문서가 준수해야 할 때 성공 기준 중 어느 것도 "실패"할 수 없음을 의미합니다. “표준 준수는 표준의 '요구 사항'을 충족하거나 충족한다는 의미입니다. WCAG 2.0에서 '요구 사항'은 성공 기준입니다. WCAG 2.0을 준수하려면 성공 기준을 충족해야 합니다. 즉, 성공 기준을 위반하는 콘텐츠가 없습니다.” — W3C 워킹 그룹 노트 여기에는 뉘앙스가 없습니다. 쿠키 동의 인터페이스로 돌아가서 이는 배너(또는 다른 구성 요소)만으로도 전체 웹 프로젝트의 WCAG 준수에 부정적인 영향을 미칠 가능성이 있음을 의미합니다. 위에서 자세히 설명한 일반적인 쿠키 동의 문제의 그림 ( 큰 미리보기 ) WCAG 적합성은 비차별 또는 시장 접근법 또는 정보에 대한 전반적인 인권에 해당하는 것으로 간주되기 때문에 유럽 연합 또는 미국의 공공 부문의 일부인지 여부에 관계없이 많은 웹 사이트에서 큰 법적 문제가 될 수 있습니다. 웹 페이지는 종종 최신 버전인 WCAG를 직간접적으로 참조하는 지침 및 규정을 준수해야 하며 해당 수준 AA 표준을 준수해야 합니다. 따라서 다음의 모든 WCAG 기준은 진정한 웹 접근성에 관한 한 단순한 시작점에 불과하다는 점을 충분히 인식하고 이 렌즈를 통해 검토됩니다 . 또한 쿠키 동의 인터페이스는 웹사이트의 모든 하위 페이지에서 구현되어 결과적으로 전체 웹사이트의 접근성과 적합성을 손상시킵니다. 따라서 결함이 있는 쿠키 배너 인터페이스가 접근성 법률에 대한 페이지의 적합성을 떨어뜨리지 않도록 하고, 더 중요한 것은 사용자가 자신의 권리에 액세스하고 행사하는 것을 배제하지 않기 위해 무엇을 찾고, 무엇을 구성하고, 무엇을 구축해야 하는지 나열해 보겠습니다. 처음부터 제대로. 점프 후 더! 아래 계속 읽기 ↓ 프런트엔드 및 UX 에 대한 Smashing Workshop을 만나보세요 . 실용적인 테이크아웃, 라이브 세션, 비디오 녹화 및 친근한 Q&A가 제공됩니다. 디자인 시스템, UX, 웹 성능 및 CSS/JS에 대해. Brad Frost, Christine Vallaure 및 기타 많은 사람들 과 함께 . 워크숍 바로가기 ↬ 기능 패널 대비 오류 # 이는 쿠키 설정 또는 권장 쿠키 세트의 전반적인 수락과 같은 중요한 제어와 관련하여 특히 관련이 있습니다. 양식 컨트롤과 텍스트가 충분히 인식될 수 있도록 하는 것이 중요합니다. 당연히 WCAG에서도 일반적으로 견고한 대비가 중요합니다. 즉, 성공 기준 1.4.3 및 1.4.11 에서 둘 다 대비 경계를 정의합니다. 해야 할 일 # 미리 만들어진 쿠키 관리 솔루션을 사용하는 경우 색상에 영향을 미치고(가능한 경우 잠재적으로 쿠키 공급업체 설정에서) 대화형 컨트롤에 충분한 색상 대비가 있는지 확인하십시오. 또한 웹사이트가 WCAG 준수를 위한 전용 대비 모드에 의존하는 경우 쿠키 관리 인터페이스로 확장(또는 영향)하는지 확인하십시오. 내 접근성 감사자 관행에서 이것이 고려되지 않고 쿠키 인터페이스에서 액세스할 수 없는(종종 브랜드가 있는) 색상 조합이 사용되어 대비 모드가 모든 색상 관련 위반을 처리한다고 생각하는 사례를 보았습니다. 그러나 웹 사이트의 대비 설정은 외부 소스에서 로드되었거나 대비 모드가 작동한 후에 타사 쿠키 배너에 영향을 미치지 않아 WCAG의 대비에 "실패"가 발생했습니다. - 관련 성공 기준. 의사 버튼 # div또 다른 쿠키 배너 문제는 유감 스럽게도 쿠키 관리 외부에서 찾을 수 있는 오류 패턴입니다 span. 이러한 컨트롤은 버튼처럼 스타일이 지정될 수 있지만 버튼의 의미론적 정보가 부족합니다. 게다가 이러한 컨트롤은 일반적으로 키보드로 초점을 맞출 수 없습니다 . 따라서 많은 심각한 장벽과 WCAG 위반이 한꺼번에 발생하고 있습니다. 예를 들어 클릭 핸들러가 있는 가장 "의사" 버튼을 상상하려고 한다면 이는 div적어도 성공 기준 2.1.1(키보드)을 위반할 것 입니다 . 이름, 역할, 값) 자체를 버튼으로 "도입"하지 않고 프로그래밍 레이블이 없기 때문입니다. 해야 할 일 # 쿠키 관리 인터페이스를 직접 구축했다고 가정할 때 가장 쉬운 방법은 위에서 언급한 유사 버튼을 실제 요소로 교체하는 것입니다. 이는 시맨틱, 포커스 가능성, 심지어 키보드 이벤트 핸들러까지 무료로 제공하기 때문입니다. 그러나 버튼에 대해 문자 그대로 이야기하지 않더라도 패턴은 동일합니다. "진짜"처럼 보이도록 스타일이 지정되었지만 의미가 없는 s div및 span에스. a이것은 , button또는 대신 에 같은 기본 대화형 요소를 구현하는 위험 신호입니다 input. 물론 이러한 의미론적 오류가 제3자 스크립트에 있어 직접적인 영향과 통제를 벗어나는 경우 상황은 훨씬 더 어려워집니다. 당연하게도 우리는 공학적 측면을 떠나 일종의 정치에 뛰어들어야 합니다. 쿠키 관리 인프라에 대한 결정이 귀하의 통제를 벗어나는 조직 내에서 일하는 경우 감독자와 관리자에게 문제를 에스컬레이션해야 합니다(특히 웹 프로젝트가 접근성 법률을 준수해야 하는 경우 뿐만 아니라). 세 가지 추상적인 단계가 발생해야 합니다. 조직은 이와 같은 기술적 결정을 변경하는 데 영향을 미치는 권한까지 "최대" 장벽과 잠재적인 법적 위험을 인식해야 합니다. 따라서 잘못된 쿠키 배너를 제공한 공급업체에 이 문제에 대해 문의해야 합니다. 귀사를 위해서뿐만 아니라 결함이 있는 쿠키 배너가 접근성과 적합성에 부정적인 영향을 미치는 다른 모든 웹 페이지와 관련하여 귀사에서 일종의 압력을 가해야 합니다. 가능한 네 번째 단계에서 회사 또는 대행사는 타사 서비스 및 HTML(및 가능한 장벽)에 대한 판매 프로세스를 반영해야 합니다. jQuery, Angular, React 및 Vue용으로 기본적으로 구축된 JavaScript UI 라이브러리입니다. 빠르고 현대적인 UI를 구축하기 위한 일관된 API 및 테마. 무료 평가판 시작 레이블이 지정되지 않은 양식 필드 # 생각해 보면 쿠키 관리 위젯에 대해 상상할 수 있는 주요 사용자 컨트롤은 양식 컨트롤 입니다 . 요소의 확인란과 상호 작용하여 수락할 쿠키 세트를 선택할 수 있습니다 form. 그리고 물론 체크박스 입력이 올바른 방식으로 작성되는 것이 중요합니다. 아아, 항상 그런 것은 아닙니다. 확인란과 해당 레이블이 시각적으로 인접해 보일 수 있지만 확인란에는 프로그래밍 레이블이 없을 수 있습니다. 이로 인해 인터페이스에 불필요한 혼란과 장벽이 추가되고 웹 접근성 표준을 살펴볼 때 적합 기준 1.3.1 도 실패합니다. 해야 할 일 # 양식 입력을 해당 레이블과 연결하는 가장 확실한 전략은 다음과 같습니다. label레이블에 대한 요소를 사용하십시오 (분명히). id라벨을 지정하려는 각 입력에 를 설정합니다 . 특성 을 추가하고 마지막 단계에서 만든 for컨트롤로 채웁니다 .id 이것은 또한 s 및 s와 같은 inputs모든 types 에 대해 작동합니다 . 다음은 적절하게 레이블이 지정된 확인란이 어떻게 표시되는지에 대한 예입니다.textareaselect Accept marketing cookies 복사 쿠키 배너 코드의 HTML에 직접 영향을 미칠 수 없는 경우 상황은 의사 버튼 주변의 상황과 유사합니다. 문제를 해결하기 위해 쿠키 서비스 제공업체에 필요한 압력이 가해졌는지 확인하십시오. 그들의 모든 고객은 그것에 대해 감사할 것이며, 그들의 사이트를 방문하는 사람들은 더욱 더 감사할 것입니다. Broken Dialog Semantics (또는 None At All) # 상당수의 쿠키 배너는 실제로 쿠키 대화 상자 이며 모달 종류입니다. 대화 상자의 맥락에서 모달은 이러한 창이 자신을 제외한 모든 것을 차단하고 자신만 액세스할 수 있음을 의미합니다. 즉, 적어도 이론입니다. 그러나 상당수의 쿠키 관리 대화 상자는 인터페이스의 모달 부분으로 표시되지만 의미 체계와 동작이 일치하지 않아 WCAG 성공 기준 4.1을 위반하는 "적극적이기를 원합니다." 중앙에 대화 부분이 있고 반투명 배경이 있는 쿠키 모달이 어떻게 생겼는지에 대한 추상 그림 ( 큰 미리보기 ) 해야 할 일 # 최근까지 권장 사항은 WAI-ARIA 역할 및 상태로 대화를 구축하고 직접 포커스 관리를 구현하는 것이었습니다(또는 Kitty Giraudel의 훌륭한 a11y-dialog 구성 요소 사용). 그러나 상황은 (대부분) 더 나은 방향으로 바뀌었습니다. 최근에 기본 요소는 합리적으로 사용되는 한

대부분의 상황에서 권장되는 지점까지 성숙해졌습니다 . 제 생각에는 접근성 측면에서 큰 승리입니다. (모달) 대화 상자를 구축하는 과거 방식에는 수동으로 생각하고 구현해야 하는 움직이는 부분과 요인(역할, 상태, 초점 동작)이 너무 많아 제대로 하기가 상당히 어려웠습니다. 이제 대화 상자를 만드는 것은 적절한 이름의 HTML 요소를 사용하는 것을 의미합니다(그리고 쿠키 대화 상자가 인터페이스 차단이 필요하다고 생각하는 경우 이를 초기화하는 것)..showModal() 지금까지 작성한 내용은 물론 제3자의 코드에 영향을 미칠 수 없는 경우에도 유효하며, 유사한 상황과 잠재적인 쿠키 동의 장벽에 대해 이전에 작성한 내용도 유효합니다. 구현 중인 타사 스크립트에서 오류를 발견한 경우(예: 포커스 트래핑 없음, dialog역할 없음, 없음 aria-modal="true", 기타 모든 것이 "모달성"을 가리키는 경우) 내부적으로 문제를 에스컬레이션하고 웹 접근성 결과에 대한 의사 결정 권한을 교육합니다. . 모달에 관한 것이 최근에 훨씬 좋아졌다는 것을 타사 개발자에게 교육할 수도 있습니다. 쿠키 배너는 처음부터 찾기 어렵습니다. # 일반적으로 적어도 시각적으로 쿠키 동의 인터페이스를 찾을 수 있는 세 가지 일반적인 위치가 있습니다. 모달 대화 상자로, 즉 중간 또는 드물게는 뷰포트의 모서리에 있습니다. 맨 위에, 때로는 고정된 방식으로; 뷰포트의 맨 아래, 때로는 고정된 방식으로 배치되기도 합니다. 그러나 일부 사람들에게 더 중요한 것은 그들이 그것을 찾기 위해 얼마나 쉽게 찾을 수 있는지입니다. 바로 이 문제를 제시하는 좋은 방법은 접근성 전문가 Léonie Watson이 얼마 전에 제공한 프레젠테이션입니다. Léonie는 노련한 스크린 리더 사용자이며 그녀의 프레젠테이션에서는 여러 웹페이지와 쿠키 배너의 배치 및 "검색 가능성"이 특히 개인 정보 보호와 관련하여 스크린 리더 경험에 어떤 영향을 미치는지 보여줍니다. 예를 들어 문서에서 중요한 콘텐츠를 찾는 기능을 방해하면 WCAG 1.3.2(의미 있는 시퀀스)에 부정적인 영향을 미칠 수 있습니다 . 해야 할 일 # Léonie의 프레젠테이션에서 쿠키 알림 찾기 가능성에 대한 모범 사례는 특히 마지막 예에서 매우 명확해졌습니다. 문서 상단에 배너를 배치하는 것이 좋습니다. 쿠키 배너에 헤드라인을 사용하고 화면 판독기 사용자가 "웹 페이지에 대한 이해"를 돕고 제목으로 탐색할 수 있도록 헤드라인을 표시하거나 시각적으로 숨깁니다 . 대화가 인터페이스의 "독점적인" 부분인 경우 적절한 의미 체계 및 상태 설명을 사용하는지 확인하여 적절한 대화 의미 체계로 돌아가는 다리를 만듭니다(자세한 내용은 위 참조). 제3자 코드 변경에 대해 이야기할 때, 지금쯤 드릴을 알고 있다고 생각합니다. 직접적인 통제가 불가능하기 때문에 "정치적 수준"에서 이 코드에 간접적으로 영향을 미치려고 합니다. Smashing Magazine으로 광고하기 결론 # 이 기사를 읽는 동안 두 가지 사실이 드러났으면 합니다. 문제에 대한 인식 , 즉 종종 사랑받지 못하는 의붓자식 인터페이스 요소가 일부 사람들이 자신의 개인 정보 설정을 관리하는 것을 더 어렵게 만들고 그 위에 법적 위험을 제기할 가능성이 있다는 것입니다. 쿠키 관리 배너로 작업할 때 직면하는 장벽을 어떻게 해결할 수 있는지에 대한 감각. 직접적인 방법은 제가 이전에 제공한 세부 사항에 특정 세부 사항에 설명되어 있으며 종종 코드, 스타일링 또는 향후 이를 방지하는 방법에 대한 전반적인 교육과 관련이 있습니다. 간접적인 방법은 동의 인터페이스를 올바르게 설정하거나 공급업체 스크립트의 내부 및 외부 정치에 영향을 미치는 경로로 이어집니다. 그리고 다시, 관련된 모든 사람을 교육하는 측면이 있습니다. 이번에는 구조화된 정보가 조직의 권한을 겨냥하여 서비스 공급자 선택이 의도하지 않은 결과를 초래할 수 있음을 보여줄 수 있습니다. 그러나 귀하와 귀하의 팀이 쿠키 동의 인터페이스에서 접근성 버그를 직간접적으로 수정하는지 여부에 관계없이 편재성과 구성 요소 아키텍처를 이점으로 볼 수 있습니다. 한 곳에서 접근성을 확보하면 다른 많은 페이지(또는 외국 웹사이트)에 더 나은 영향을 미칠 수 있습니다. 쿠키 배너의 사용자 경험 측면에 대한 시야를 넓히고 개인 정보 보호 설정을 적어도 EU 법률에 따라 쾌적하고 정중한 참여로 전환하는 방법에 대해 알아보려면 Vitaly의 멋진 읽기 "개인 정보 UX: 더 나은 쿠키"를 읽어보십시오 . 동의 경험 ”.