WCAG와 같은 접근성 표준의 주요 요구 사항 중 하나는 웹 사이트 또는 응용 프로그램이 자바 스크립트를 사용하지 않고 표시되거나 일종의 비 JS 대안을 제공한다는 것입니다. 나는 초기 조사를했는데 웹 소켓과 관련하여 이것에 대한 많은 정보를 찾을 수 없었다. 웹 소켓이 AJAX와 비슷한 것으로 취급해야한다고 생각합니까?HTML5 웹 소켓과 접근성 표준의 호환성은 얼마나됩니까?
웹 소켓은 유용한 기능을 수행하기 위해 JavaScript가 필요하기 때문에 비 자바 스크립트 대안을 제공해야하는 표준이있는 경우 웹 소켓을 사용하지 않는 JavaScript 이외의 대안을 제공해야합니다. 예, 웹 소켓은 AJAX와 같습니다. 그것들은 AJAX가 제공하는 일회성 요청 - 응답보다는 오히려 지속적인 2-way 연결을 만드는 단지 방법입니다. 당신은 AJAX를 치료하는 것처럼 그들을 치료해야합니다.
WCAG 1.0에서는 JavaScript에 대한 대안을 제공해야하지만 WCAG 2.0은 기술 중립적입니다. JavaScript의 대안을 요구하는 대신, 클라이언트 쪽 스크립트를보다 쉽게 사용할 수있는 웹 페이지를 만들기 위해 a set of techniques을 제공합니다. 모든 사용자가 자바 스크립트를 사용할 수있는 것은 아니며, 전체적으로 또는 기본적으로 비활성화되어있는 브라우저를 선호하는 사용자가 여전히 있습니다. 그러나 접근성 기술은 오늘날 자바 스크립트의 특정 용도를 처리 할 수 있으므로 자바 스크립트가 아닌 대체 서비스가없는 경우에도 액세스 가능한 사이트를 작성할 수 있습니다.
브라이언의 답변은 좋지만 몇 가지 추가 정보를 추가 할 것으로 생각했습니다.
여기에는 기술과 규정 준수라는 두 가지 문제가 있습니다.
WCAG 1.0이 필요한 이유가있는 경우 규정 준수에 관한 한 비 JS 버전이 필요합니다. 왜냐하면 WCAG 1.0은 이렇게 말합니다. 이전에는 일부 스크린 리더 사용자가 화면 판독기에 문제가 발생했기 때문에 JS를 사용하지 않도록 설정 했었지만 몇 세대 전의 기술이었습니다. recent survey of screenreader users on the web은 Javascript가 활성화 된 상태에서 98.6 %를 나타 냈습니다.
지금까지 기술이가는대로, 자바 스크립트 및 접근성 문제 정말 자바 스크립트 자체와는 아무 상관이 없다 : 접근성의 문제는 무엇인가 (보통 자바 스크립트)는 DOM를 통해 UI를 조작 사실과해야 할 . 접근성 문제가있는 UI의 조작입니다. 결과 DOM이 접근 가능하고 화면 판독기가 적절하게 변경 사항을 처리하도록주의를 기울여야합니다. 예를 들어, ARIA 라이브 영역을 사용하여 스크린 리더가 새로운 내용을 읽을 수 있도록하거나 키보드 포커스가 사라지지 않도록하고 예상치 못한 곳에서 끝납니다.
정의에 의해 UI를 거의 변경하지 않는 자바 스크립트는 접근성 문제가 없습니다. 웹 소켓, 웹 작업자, 로컬 저장소 등은 접근성 문제가 없습니다. 중요한 것은 나중에 DOM을 업데이트하는 경우입니다.