분류 Reactjs

개발자를 위한 웹 접근성 가이드 북

컨텐츠 정보

  • 조회 424 (작성일 )

본문

React 용 네이티브 UI 구성 요소 인 KendoReact에 대한 접근성 컴플라이언스 (Section 508, WCAG 2.0 및 WAI-ARIA)를 구현하는 과정에서 우리는 기본 및 고급 접근성 주제에 대해 많은 것을 배웠습니다. 이 기사를 통해 우리의 목표는 수준에 관계없이 웹 접근성에 관한 동료 엔지니어를 소개하고 실제 지식과 모범 사례를 공유하는 것입니다.


https://www.telerik.com/blogs/web-accessibility-guidebook-for-developers?utm_medium=cpm 


접근성 소개


W3C의 정의에 따르면 접근성은 웹 사이트, 도구 및 기술이 장애가 있는 사람들이 사용할 수 있도록 설계되고 개발되었음을 의미합니다. 보다 구체적으로, 사람들은 웹을 인식, 이해, 탐색 및 상호 작용하고 웹에 기여할 수 있습니다.


내게 필요한 옵션에 대한 한 가지 좋은 예는 웹 사이트를 보지 않고도 웹 사이트를 사용할 수 있는지 여부입니다. 어떻게 시력을 사용하여 콘텐츠를 소비하거나 마우스를 사용하여 상호 작용할 수 없는 경우 작업 개발에 많은 시간과 노력을 쏟을 수 있습니까? 대신에 UI를 설명하는 화면 판독기를 듣고 기존 마우스 또는 키보드 입력을 통해 탐색하지 않아도 된다는 것을 상상해보십시오.


접근성이 종종 무시되는 이유 


접근성이 편재성이 아닌 많은 이유가 있지만 이상적으로는 그렇지만 세 가지 이유가 있습니다.


첫째, 잘 이해하지 못하는 것을 수용하기가 어렵습니다. 대부분의 경우, 우리가 부족한 동기가 아니라 오히려 장애가 사람들이 우리 웹 사이트와 상호 작용하지 못하게 하는 방법에 대한 교육입니다. 여기에는 장애 유형이 무엇인지, 장애 유형을 수용하는 방법에 대한 지식 부족이 포함됩니다. 우리는 문제의 내용을 알지 못합니다.


둘째, 애플리케이션에 액세스 할 수 있게 하려면 많은 작업이 필요합니다. 표준의 전제를 이해하고 시작하여 필요한 기능과 기능을 앱에 맞게 설계해야 합니다. 그런 다음, 귀하의 접근 방식이 원하는 결과를 얻었는지 여부를 테스트합니다. 그리고 많은 테스트는 수동으로만 수행 할 수 있습니다. 이 기사에서 설명한 방법을 사용하면 이 작업을 더 쉽게 수행 할 수 있지만 여전히 심각한 문제에 대해 이야기하고 있습니다.


셋째, 현대의 의사 결정을 옳고 그름으로 결정하는 경제적 논쟁입니다. 대부분의 경우 고객 (또는 사용자)의 소수가 장애에 영향을 받을 수 있습니다. 이는 다음 릴리스를 위해 접근성 향상을 구현할 것을 정당화하는 역할을 합니다 . 기업이 실제로 애플리케이션을 이전하지 않은 것처럼 느껴질 수 있는 작은 부분의 사용자에게 서비스를 제공하는 대신 다수에게 이익을 주는 것에 초점을 맞추는 것이 훨씬 쉽습니다.


접근성이 중요한 이유 


접근하기 쉬운 웹 사이트 구축의 이점을 고려하는 데 시간을 할애하는 것은 가치가 있습니다. 왜냐하면 웹 사이트가 어렵고 시간이 오래 걸리므로 비용이 많이 드는 사업이기 때문입니다. 그러나, 그것을 하는 확고한 이유가 있습니다.


윤리학 


장애를 가진 사람들은 매일 많은 문제를 다루고 있습니다. 고객이나 사용자가 웹 앱과 상호 작용할 수 있도록 하는 것이 인간의 평범함입니다.


시장 


전 세계적으로 10 억 명의 인터넷 사용자 중 20 %가 장애를 가지고 있다는 데이터가 있습니다. 이것은 여전히 ​​소수이지만, 우리 대부분이 생각하는 것보다 훨씬 많은 사람들로 구성됩니다.


법률 


이 도메인의 법률이 발전함에 따라 귀하의 비즈니스가 법으로 접근 가능하도록 요구 될 가능성이 높아집니다. 다음 섹션에서 이 정확한 주제에 초점을 맞추어 다시 살펴 보겠습니다.


사용자 경험 


접근성 지침은 사람들이 귀하의 웹 사이트에 보다 쉽게 ​​액세스하고 사용할 수 있도록 하기 위해 고안되었습니다. 부작용으로 인해 대부분의 경우 유용성이 향상되고 장애가 없는 사용자를 포함한 모든 사용자에게 직접적인 혜택을 줍니다. 예를 들어, 읽을 수 있는 텍스트는 시력이 좋지 않은 사람뿐만 아니라 모든 사용자에게 도움이 됩니다.


공학 


접근성을 위한 우수 사례는 일반적으로 좋은 엔지니어링 및 설계 원칙입니다. 종종 액세스가 불가능한 잘못 작성된 코드입니다. 우리 공예의 숙달을 위해 노력하는 우리에게는 접근성이 좋은 일을 하는 것입니다.


평판 


귀하의 경쟁자보다 접근하기 쉬운 웹 사이트를 갖는 것은 경쟁 우위입니다. 또한 브랜드에 대한 호의를 창출하는 데 도움이 될 수 있습니다.


SEO 


검색 엔진 최적화 (SEO) 및 웹 접근성에 대한 우수 사례 간에는 일부 중복이 있습니다. 예를 들어 레이블, 비디오 대본, 이미지 캡션 및 제목 및 헤더 태그 사용과 같은 설명 속성을 적절히 사용하여 의미론적 HTML을 작성하면 웹 사이트의 SEO 및 접근 가능성이 향상됩니다.


법률 제정 


전세계의 현행법은 접근성이 웹의 필수 기능이 되는 방향으로 움직이고 있습니다. 미국에서는 장애인 법 (Americans with Disability Act, ADA)이 접근성을 보장합니다. 많은 선진국에는 유사한 법률이 있습니다. 예를 들어 영국에는 2010 년 평등법이 있습니다. 실질적으로 이러한 법률은 공공 부문 조직과 기업이 법으로 웹 콘텐츠 접근성 지침 (WCAG)을 준수해야 한다는 것을 의미합니다.


고객 및 사용자가 생각해야 할 것은 아닙니다. 50 명 이상의 직원이 있는 조직의 경우 장애인을 수용 할 수 있도록 해야 합니다. 즉, 내부 웹 도구에 액세스 할 수 있어야 합니다.


또한, 정부를 위해 일하는 계약자 인 경우, 위와 더불어 귀하의 업무에서 재활법 508 항을 준수해야 합니다. 법으로 모든 미국 정부 서비스는 제 508 항을 따라야 합니다. 자세한 내용은 제 508 항에 대한 자세한 내용을 제공합니다.


이 법칙은 좋은 의도를 나타내는 것이 아닙니다. 점점 더 많은 법률 회사가 접근성 법규에 따라 법적 조치를 취하고 있습니다. 진행 상황에는 "접근성과 법"이라는 추가 읽기 주제에 대한 자세한 기사가 있습니다.


장애 유형 및 접근성 우수 사례 


청력, 시력, 운동 및 인지 장애의 네 가지 주요 장애 유형이 있습니다. 각 유형에는 다양한 조건이 포함됩니다. 웹과 상호 작용할 때 서로 다른 문제를 야기하며 이러한 문제를 해결하기 위해 다양한 접근 방식이 필요합니다. 각 유형의 장애 유형을 다루는 모범 사례를 살펴 보겠습니다. 이러한 사례의 대부분은 우리가 사용하는 기반 기술에 관한 것이 아니라 소프트웨어를 설계하는 방법에 관한 것입니다. 즉, 개발 프로세스에 참여하는 모든 사람이 보다 나은 접근성에 기여할 수 있습니다.


청각 장애 (청각 장애) 


청각 장애는 가벼운 청력 손실에서 청각 장애까지 다양합니다. 이러한 사용자를 돕는 가장 좋은 방법은 중요한 정보를 전달하기 위해 소리에만 의존하지 않는 것입니다. 대신 지원을 위해 다른 미디어를 병렬로 추가하십시오. 예를 들어 비디오를 사용하는 경우 자막이 전체 자막을 지원하는지 확인하십시오. 오디오를 사용하는 경우 사본을 제공하십시오. 자막과 성적 증명서는 가득 차 있어야 하며 중요한 라인을 놓치지 않아야 합니다. 다음 단락에서는 가독성을 위한 지침을 나열합니다. 자막 및 성적에 강력하게 적용됩니다. 이 외에도 비디오 및 오디오 모두에 대해 배경 잡음이 최소화 되도록 하여 전달 된 정보가 최대한 들릴 수 있도록 하십시오.


시각 장애 - 저시력 


저시력을 수용하는 주요 방법은 판독 가능한 인터페이스를 갖추는 것입니다. UI 요소는 크고 명확해야 합니다. 텍스트는 보다 복잡하지만, 이후 단락에서는 가독성을 위한 지침을 나열합니다. 그들은 시력이 약한 사람들을 돕기 위해 고안되었습니다.


대조는 또 다른 중요한 측면입니다. UI의 요소와 색상 사이의 높은 대비는 시력이 약한 사람들을 도울 것입니다. 이 조건을 가진 사람들이 대비가 충분한 지 검사하는 도구가 있습니다. 웹 접근성 이니셔티브 (WAI)에서 권장하는 도구를 찾을 수 있습니다. 요즘 사용되는 대부분의 페이지 디자인에서는 콘트라스트가 실제로 문제가 됩니다. 고 대비 테마는 종종 일반 테마와 잘 작동하지 않으므로 좋은 대조를 이루려면 웹 사이트의 시각적 호소력을 희생하지 않는 것이 좋습니다. 좋은 절충안은 언어를 변경하는 옵션과 마찬가지로 웹 사이트에 옵션으로 고 대비 테마를 포함 시키는 것입니다.


Web accessibility - Contrast 


시각 장애 - 실명 


맹인은 화면 판독기를 사용합니다. 이러한 응용 프로그램은 HTML을 구문 분석하고 자연어를 사용하여 사용자에게 설명합니다. 화면 판독기 개발은 구체적인 내용이므로 이 기사의 뒷부분에서 독점적으로 다루게 될 것입니다. 또한, 실명 증을 가진 사용자는 입력 장치가 다를 것입니다. 마우스를 사용하면 시력이 필요합니다. 시각 장애인은 완전한 키보드 지원이 필요합니다.


시각 장애 - 색맹 


색맹은 하나의 조건이 아닙니다. 색맹의 다른 유형이 있습니다. 다음 설명은 매우 단순합니다. 신이영증은 녹색 빛을 감지하는 것이 어려우며 가장 일반적입니다. 적색 빛을 감지하는 데 어려움을 겪는 것은 원시라고 불리우며 일반적이지 않습니다. 이 두 조건의 가시적 인 유령은 다소 비슷하며 조건은 일반적으로 적색 - 녹색 색맹으로 알려져 있습니다. Tritanomaly는 파란 색의 인식 문제이며 매우 드뭅니다.


각 조건의 심각도는 다양합니다. 경미한 지각 문제에서 부터 그 색을 인식하지 못하는 정도까지 다양 할 수 있습니다. 색상 인식이 부분적으로 영향을 받는 경우 접미사 -nomaly를 사용하고 색상을 인식 할 수 없는 경우에는 nopia를 사용합니다. 색소 침착증은 모든 것을 회색조로 보는 조건이며 매우 드뭅니다. 색상 인식의 변화는 단일 색상이 아니라 전체 가시 스펙트럼에 영향을 미칩니다.


Types of colorblindness 


당신의 초기 아이디어는 색맹이 있는 대부분의 사람들이 볼 수 있는 색을 선택하는 것일 수 있습니다. 장애의 다양성으로 인해 이상적인 것은 아니지만 대부분의 경우 오렌지와 블루가 정상적으로 작동합니다. 이것은 인터넷이 너무 많이 푸른 것을 좋아하는 이유 중 하나입니다.


색맹 사람들이 볼 때 웹 사이트가 어떻게 보이는지 시뮬레이트 하는 도구가 있습니다. 그것들을 사용하여 문제가 있는지 감지 한 다음 문제가 있는 유형의 조건에 대해 선택적 테마를 설계하고 추가 할 수 있습니다. 그래도 사용자는 해당 테마를 찾아서 전환 할 수 있어야 합니다.


가장 효율적인 솔루션은 색상만으로 중요한 정보를 전달하지 않는 것입니다. 모양, 기호, 애니메이션 및 기타 창의적인 수단을 사용하여 문제를 해결할 수 있습니다.


운동 장애 


빠른 및 / 또는 반복적 인 행동, 버튼을 잡아야 하는 행동, 시간 제한이 있는 행동 -이 모든 것은 운동 장애가 있는 사람에게는 힘들고 신체적 고통을 유발할 수 있습니다. 당신은 그들을 피할 필요가 있지만 그렇게 간단하지는 않습니다. 다음 예제는 그 이유를 설명합니다. 이동하려는 버튼을 유지해야 하는 슬라이더가 있다고 가정합니다. 귀하의 솔루션은 키를 두드려 슬라이더를 움직일 수 있지만, 단계가 너무 작으면 결과는 반복적인 동작으로 향상되지 않습니다. 일반적인 규칙은 사용자가 웹 사이트를 디자인해야 하므로 사용자는 키보드 만 사용하고 마우스 만 사용하면 편리하게 사용할 수 있습니다.


운동성 및 감각 과부화와 관련된 인지 장애 


멀미 또는 감각 과부하 (예 : 간질)를 일으킬 수 있는 몇 가지 패턴이 있습니다. 일반적으로 흔들림, 밝은 불빛과 같은 빠른 효과가 빠르게 번쩍입니다 (초당 3 회 이상). 급격한 운동 패턴을 반복하면 같은 문제가 발생할 수 있습니다. 반복적이지만 천천히 움직이는 페이지의 좋은 예는 떨어지는 눈송이의 애니메이션입니다. 우리는 종종 겨울 방학 동안 볼 수 있습니다. 한 페이지의 콘텐츠에서 일시적인 전환을 사용하는 예리한 변경도 문제가 됩니다. 대신 부드러운 전환을 사용해야 합니다. 좋은 방법은 문제가 되는 영향을 피하는 것이지만 사용하려는 경우 사용자가 문제를 일으키지 않도록 할 수 있습니다.


인지 장애 - 학습 장애 


단순성이 핵심입니다. 시나리오를 단순하게 만들고, 인터페이스를 단순하고 혼란으로부터 자유롭게 하십시오. 간단한 언어를 사용하고 멋진 단어는 피하십시오. 항상 간결한 지침과 간결한 정보를 제공하십시오. 정보의 양은 Goldilocks 원칙을 따라야 합니다. 너무 적으면 충분하지 않지만 너무 많이 추가하면 일부 사용자가 산만하게 됩니다. 사용자에게 불필요한 부담을 줄 수 있는 시간 제한을 피하십시오.


인지 장애 - 실독증 


실독증 (Dyslexia)은 장애 유형으로 사람들이 읽는 것을 어렵게 만듭니다. 실독증이 있는 사람들은 글자를 혼동하거나 함께 회전하거나 붐비는 모습을 보게 됩니다. 다음 단락에서는 가독성을 위한 지침을 나열합니다. 그들은 난독증의 문제를 해결하는 데 강력하게 적용됩니다.


Accessibility - Dyslexia 



가독성에 대한 팁 


가독성이 뛰어나 많은 사람들에게 장애가 없는 사용자도 웹 사이트에 액세스 할 수 있습니다. 청각 장애가 있거나 읽을 수있는 텍스트가 있는 사람들은 읽을 수 있는 자막 및 성적표를 사용하여 시력이 약하거나 실독증이 있는 사람들에게 도움이 됩니다. 엄지 손가락의 규칙은 간단하고 깨끗한 산세리프 글꼴을 큰 글꼴 크기로 사용하는 것입니다.


공간 문제. 예를 들어, 긴 줄은 읽기가 어렵기 때문에 한 줄에 70자를 사용할 수 있습니다. 자막의 경우 권장 한도는 35 자입니다. 캐릭터가 숨쉴 만큼 충분한 공간을 제공하십시오. 1.5x 줄 간격은 괜찮습니다. 공간의 주제에 대해 대문자로 된 텍스트는 읽기가 어렵기 때문에 대소 문자를 혼용하십시오. 독서 속도 또한 중요하므로 자동 또는 자막의 경우 텍스트를 앞당기지 마십시오. 단어 당 0.3 초 이상 화면에 유지하십시오.


퍼즐의 핵심 부분은 대조입니다. 배경 이미지는 일반적으로 텍스트를 흐리게 만듭니다. 좋은 글꼴은 대비를 강화하기 위해 글자 주위에 테두리가 있지만 배경 이미지를 완전히 피하고 텍스트와 잘 어울리는 단색 배경을 제공하는 것이 좋습니다.


IT 산업은 가독성을 높이기 위해 최적화 된 멋진 글꼴을 만들었습니다. 그들 중 일부는 고려해 볼 수 있습니다. Opendyslexic과 Inter는 좋은 예입니다.

OpenDyslexic specialized font 


보조 기술 소개 


보조 기술은 장애인을 돕기 위해 고안된 모든 소프트웨어 및 하드웨어를 포함하는 업계 용어입니다. 입력 장치에는 입 스틱, 헤드 완드, 대형 트랙볼, 특수 키보드, 음성 인식 소프트웨어가 포함됩니다. 출력 장치에는 화면 돋보기, 화면 판독기, 점자 디스플레이, 보청기, 자연어 인터페이스가 있는 소프트웨어 등이 포함됩니다. 이들 중 일부는 기존 기술을 향상 시키고 다른 기술은 컴퓨터와 상호 작용할 수 있는 대체 방법을 제공합니다.


Assistive devices - keyboard 


대부분의 보조 기술은 운영 체제 수준에서 작동하며 웹 개발자는 제대로 작동하려면 추가 작업을 수행 할 필요가 없습니다. 그러나 화면 판독기에서는 상황이 좀 더 복잡해집니다.


화면 판독기 최적화 


본질적으로 화면 판독기는 HTML을 구문 분석 한 다음 자연어를 사용하여 설명하고 설명합니다. 음성 설명의 품질은 코드의 품질에 직접적으로 달려 있습니다. 따라서 자연히 화면 판독기는 웹 개발자가 웹 사이트를 보다 쉽게 이용할 수 있게 만드는 주요 관심사입니다. 다음 단락에서는 스크린 리더를 위해 웹 자산을 최적화 할 때 유용한 사례를 살펴 보겠습니다.


시맨틱 HTML 작성 


화면 판독기의 작업을 올바르게 수행하는 데 도움이 되는 가장 좋은 방법은 의미론적 HTML을 작성하는 것입니다. 즉 유효한 HTML을 작성하고 모범 사례를 따르며 의도 된 용도에 따라 요소를 사용하는 것입니다. 예를 들어 무언가가 보이고 버튼처럼 동작하는 경우 <div>가 아닌 버튼으로 만듭니다. 제목 일 경우 <h> 태그를 사용하고 일부 인라인 CSS는 사용하지 마십시오.


html 요소의 의미에 대한 공식 정의는 HTML의 생활 표준에서 찾을 수 있습니다.


실생활에서, 이것은 당연히 그렇게 간단하지 않습니다. 다음 섹션으로 넘어갑니다.


사양 따르기 


섹션 508은 장애 상태에 상관없이 모든 사용자가 기술에 액세스 할 수 있도록 표준을 제공하기 위한 초기 노력입니다. 즉, 유효한 HTML을 작성해야 합니다. 섹션 508에 포함 된 체크리스트가 있습니다.


모든 근본적인 기술과 마찬가지로 인터넷에는 여러 표준화 기구가 있습니다. W3C (World Wide Web Consortium)가 그 중 하나이며 WAI (Web Accessibility Initiative)도 그 일부입니다. WAI는 개발자를 위한 웹 접근성의 일반적인 표준 인 WCAG (Web Content Accessibility Guidelines)를 개발했습니다. WCAG는 제 508 항의 대안이 아니라 오히려 그 위에 구축됩니다.


서로 다른 유형의 장애를 논의 할 때 우리가 이전에 수행 한 설계 관행은 WCAG에 자세히 설명되어 있습니다. WCAG는 적극적으로 개선되고 있는 생활 표준이라는 점에 유의해야 합니다. 이 자원을 쓰는 시점에서 가장 최신 버전은 2.1입니다.


WAI는 접근성 지침을 충족하는 코드를 작성하는 기술 표준 인 WAI (Web Accessibility Initiative) 인 WAI-ARIA (Accessible Rich Internet Applications Suite)를 개발했습니다. 스크린 리더가 제대로 작동하려면 개발자가 이 사양을 따라야 합니다. 간결성을 위해 다음 단락에서는 WCAG 및 WAI-ARIA를 "사양"이라고 지칭합니다.


WAI-ARIA 소개 


WAI-ARIA는 UI 구성 요소에 보다 구체적인 의미를 추가 할 목적으로 HTML 속성 인 많은 역할을 정의합니다. 보조 도구는 구성 요소 역할을 인식하고 이 정보를 사용하여보다 자세한 정보를 사용자에게 제공합니다. 모든 UI 구성 요소는 의미 있는 역할 속성으로 장식되어야 합니다. 사용 가능한 역할 목록은 이 문서를 참조하십시오.


WAI-ARIA는 구성 요소의 상태, 속성 및 / 또는 목적에 대한 정보를 가져 오는 aria- * 속성 목록을 정의합니다. 각 WAI-ARIA 역할은 많은 aria- * 속성을 지원합니다. 각 역할에 사용할 수 있는 전체 속성 목록은 이 기사를 참조하십시오.


WAI-ARIA는 다양한 UI 구성 요소와 위젯을 개발할 때 많은 디자인 패턴과 관행을 권장합니다. 이를 준수함으로써 우리는 보조 기술의 성능을 더욱 향상시킵니다.


앞에서 설명한 것처럼 키보드 탐색은 웹 접근성의 주요 부분입니다. 이 기사에서 WAI-ARIA는 키보드로 일관된 사용자 경험을 구현하는 방법에 대한 자세한 가이드 라인을 제공합니다.


자동화 된 테스트 


따라야 할 많은 준수 규칙을 포함하는 검사를 자동으로 수행 할 수 있는 다양한 스캐너가 있습니다. 예를 들어, 대부분의 자동화 소프트웨어는 누락 된 속성과 요소를 쉽게 검사하고 색 대비를 확인하거나 HTML의 유효성을 검사 할 수 있습니다. 좋은 방법은 최소한 분기 별 웹 사이트 스캔을 하는 것입니다. 정말로 헌신적 인 사람이라면 이 단계를 CI 및 CD 프로세스에 포함 시킬 수 있습니다. 다음은 특별한 순서 없이 양질의 스캐너 목록입니다.


수동 테스트 


불행히도 자동화는 큰 그림의 작은 부분을 차지할 수 있습니다. 의미 있는 결과를 얻으려면 수동으로 웹 사이트를 테스트해야 합니다. 이러한 테스트를 수행하는 가장 실용적인 방법은 눈을 감고 키보드와 스크린 리더 만 사용하여 검토중인 웹 사이트에서 다양한 작업을 수행하는 것입니다.


옆면 : 개인적으로 이것은 접근성 테스트가 실제로 얼마나 어려운 지를 발견한 시점입니다.


Accessibility - Blind Testing 


Navigation 


눈을 감고 마우스를 사용할 수 없습니다. 어두운 곳에서의 키보드 탐색은 시각적 인 입력보다 훨씬 어렵습니다. 일단 당신이 화면을 보지 않으면 당신이 원했던 것만큼 당신의 솔루션이 잘 작동하지 않을 수도 있습니다. 당신은 아마도 당신이 놓친 시나리오를 발견 할 것입니다. 간단히 말해, 훌륭하고, 일하고, 키보드 탐색 기능을 제공하는 것은 매우 어렵습니다.


청각 복잡성 


시장은 여러 개의 스크린 리더를 제공하며 대개 이해하기가 어렵습니다. 당신은 당신이 듣는 것을 이해하기 위해 고투할 수 있습니다. 그 이유는 화면 판독기가 TTS (텍스트 음성 변환)를 사용하여 화면을 읽지 못하기 때문입니다. 그들의 작업은 어렵습니다. 구조를 이해할 수 있도록 UI를 충분히 자세히 설명해야 합니다. 스크린 리더는 단순한 시나리오에서 간단한 구조를 제공 할 때만 잘 이해할 수 있습니다. 따라서 웹 사이트의 정보 아키텍처를 단순화하기 위해 열심히 노력해야 합니다.


불일치 


각 스크린 리더는 스펙에 대한 독자적인 해석이 있으며 각 브라우저에서 약간 다르게 작동합니다. 사양에 따라 모든 화면 판독기가 의미 있는 출력을 제공하기에 충분하지 않은 많은 회색 영역이 있습니다. 이 경우 독자는 대부분의 독자와 브라우저 조합에서 정상적으로 작동하는 절충안을 작성해야 합니다.


실제로 테스트 목적으로 잘 작동하는 몇 가지 조합을 발견했습니다.


Jaws


Jaws는 시장에서 가장 오래된 스크린 리더 중 하나입니다. 이것은 이것이 가장 널리 쓰이는 툴 중 하나라는 것을 의미합니다. 수많은 사용자가 있으므로 응용 프로그램이 이를 지원하는지 확인해야 합니다. Jaws는 WAI-ARIA 이전에 처음 출시되었습니다. 나이가 많다는 것은 Jaws가 여러 가지 기존 사용 사례를 지원해야 한다는 의미입니다. 결과적으로, 그것은 종종 사양을 따르지 않고 작업하기가 어렵습니다. 우리는 Jaws가 IE와 Firefox에서 가장 잘 작동한다는 것을 발견했습니다. Jaws는 상용 제품입니다.


ChromeVox


ChromeVox는 최신 독자이며 (이 기사 작성 시점) 결과적으로 사양에 가장 잘 부합합니다. 어린 나이는 아직도 별로 인기가 없다는 것을 의미합니다. Chrome에서 가장 잘 작동합니다. Chromevox는 무료입니다.


NVDA


NVDA는 스펙을 잘 준수하는 또 다른 새로운 리더입니다. Jaws 이후 가장 인기 있는 스크린 리더이며 Firefox에서 가장 잘 작동합니다. NVDA는 무료입니다.


VoiceOver


VoiceOver는 MacOS에 통합되어 있으며 기본 Safari에서 가장 잘 작동합니다. Jaws와 NVDA (Source : WebAIM Survey) 이후 세 번째로 많이 채택 된 스크린 리더입니다.


Narrator


내레이터는 Windows 10에 내장되어 Edge에서 가장 잘 작동합니다. 이 글을 쓰는 시점에서 WAI-ARIA 사양을 완전히 구현하지 못했습니다.


제한 사항의 예 


다른 독자는 다른 도전을 제시 할 수 있습니다. 예를 들어, Jaws 및 VoiceOver는 키보드 이벤트를 방지하여 예기치 않은 부작용을 일으킬 수 있습니다. 이것은 "가상"커서 기능과 관련된 자체 탐색을 가능하게 하기 위해 수행됩니다. 다른 경우에는 독자가 아직 특정 브라우저에서 특정 WAI-ARIA 역할 또는 속성을 지원하지 않는다는 것을 알 수 있습니다. 수동 테스트의 목표는 이러한 한계를 찾아 내서 해결하는 것입니다.


수동 테스트 결론 


독자가 브라우저에서 잘 작동하면 규칙이 없고 가능한 시나리오가 많아도 사용자가 주로 브라우저에서 사용한다는 확신을 줄 수 있습니다. 그러나 제한된 리소스로 작업하기 때문에 위의 인기 있는 조합에만 초점을 맞추고 가능한 모든 조합의 독자와 브라우저를 다루는 대신 자주 테스트하는 것이 좋습니다.


제 3 자 테스트가 마지막입니다. 


장애가 있는 사람과 함께 테스트하거나 고객으로부터 접근성 피드백을 받는 것이 좋습니다. 가장 좋은 방법은 사내 수동 및 자동 테스트를 통해 숙제를 마친 후에 해야 합니다. 먼저 사용자 경험이 완전히 깨지지 않았는지 확인하는 것은 우리의 책임입니다. 그래야만 사용자로부터 의미 있는 피드백을 얻을 수 있습니다.


조직의 최상의 업무 관행 


조직 내에서 할 수 있는 일이 있어 충분한 사람들이 주요 액세스 가능성 고려 사항을 알고 있는지 확인하십시오. 우선, 이런 식으로 의사 결정을 내릴 필요가 있을 때마다 최소한 한 명 이상의 사람이 접근성 요구 사항을 제기 할 것임을 확신 할 수 있습니다.


교육 


문제를 해결하는 첫 단계는 먼저 문제를 인식하는 것입니다. 그래서 주제에 대한 팀 교육에 투자하는 것이 좋습니다. 옳은 일을 하는 우리의 동기에 관계없이 웹 사이트를 보다 쉽게 이용할 수 있도록 하기 위해 해야 할 일이 무엇인지 알지 못하면 이 분야에서 진전을 이루지 못할 것입니다.


또한 접근성은 한 사람의 책임이 아닙니다. 엔지니어와 디자이너에서 관리에 이르기까지 웹 앱에서 작업하는 모든 사람들은 이를 고려해야 합니다. 동료 엔지니어들과 지식을 공유하고 공유하는 것도 이 기사의 주요 동기입니다.


문서


이전 부분에서 이미 설명한 것처럼 접근성은 정확한 과학이 아닙니다. 종종 눈에 띄지 않는 해결책이 없는 회색 영역에서 자신을 발견하게 됩니다. 이러한 상황에서 가장 좋은 방법은 접근 방식을 문서화하는 것입니다. 그 문서에서, 당신은 당신의 현재 구현 뒤에 추론을 포함 시킬 수 있으며 당신이 선택한 WCAG 규칙을 인용 할 수 있습니다. 이 문서는 팀이 지식을 공유하고 웹 사이트의 일관성을 개선하고 회색 영역 수를 줄이는 데 도움이 됩니다. 법원에서 귀하의 결정을 변호 할 필요가 있는 경우, 귀하의 사례를 보호 할 수 있는 문서가 있어야 합니다.


사용 편의성과 접근성이 동일하지 않음 


357/5000 유용성과 접근성에는 많은 공통점이 있습니다. 이 기사에서 다루는 대부분의 접근성 관행은 모든 사용자에게 도움이 될 것입니다. 그러나 유용성과 접근성은 동일하지 않습니다. 유용성에 막대한 투자를 했을 수도 있지만 자동으로 접근성을 다룬 것은 아닙니다. 접근성은 각자의 주의가 필요하다는 것을 명심하십시오.


앞에서 설명한 것처럼 접근성에는 여러 회색 영역이 있습니다. 때로는 접근성 솔루션이 사용성 솔루션과 모순 될 수 있습니다. 이러한 경우에 가장 좋은 방법은 대다수의 사용자를 대상으로 하기 때문에 유용성을 희생하지 않는 것입니다. 대신, 우리는 창의력을 발휘하고 문제를 해결해야 합니다.


액세스 가능한 도구 사용 


웹 접근성은 어렵습니다. 좋은 결과를 얻는 핵심 방법은 접근 가능한 도구를 사용하는 것입니다. 예를 들어, 간단한 블로그 나 웹 사이트를 원한다면 WordPress에서 접근성을 관리 할 것입니다. KendoReact UI 구성 요소 라이브러리에 대한 우리의 작업으로, 우리는 같은 방식으로 여러분을 도울 것을 목표로 합니다. UI 구성 요소는 처음부터 액세스 가능성을 염두에 두고 설계되었으므로 대부분의 작업을 수행 할 필요가 없습니다.


결론


이것은 KendoReact 팀의 경험을 요약하면서 React에 대한 UI 구성 요소 라이브러리의 접근성을 연구하면서 웹 접근성에 대한 기사의 마지막 주제입니다. 이 자료의 주요 목표는 주제에 대한 인지도를 높이는 것입니다. 우리는 접근성이 얼마나 중요한지를 알려주고 접근 가능한 웹 사이트를 구축 할 때 발생하는 어려움을 효율적으로 해결할 수 있는 유용하고 실질적인 아이디어를 제공하기를 바랍니다.