전 세계적으로 10억 명이 넘는 사람들이 장애가 있습니다. 개발자는 접근성을 극대화하여 해당 사용자의 디지털 경험을 개선하는 데 중요한 역할을 합니다. 다음은 웹 전문가가 이러한 사용자에게 더 나은 서비스를 제공하기 위해 따를 수 있는 6가지 접근성 모범 사례입니다. 세계보건기구(WHO)의 장애에 관한 세계 보고서( World Report on Disabilities )에 따르면 전 세계적으로 10억 명이 넘는 사람들이 어떤 형태의 장애를 가지고 살고 있습니다. 인구의 15%입니다. 미국에서는 그 수가 훨씬 더 많습니다. CDC는 인구의 25% 이상이 장애가 있는 것으로 추정합니다 . 이러한 장애는 다양한 형태를 취하며 가장 흔한 것은 신체적, 인지적, 청각 및 언어 장애입니다. 장애가 있으면 사람들이 웹과 상호 작용하는 방식에 영향을 줄 수 있습니다. 시각 장애가 있는 사람은 화면 판독기 를 사용할 수 있고 신체 장애가 있는 사람은 음성 제어 소프트웨어를 사용하여 탐색할 수 있습니다. 그리고 우리 UX 북 클럽 이 Designing Interface Animation 에서 배웠 듯이 전정 장애가 있는 사람은 어지러움을 피하기 위해 애니메이션(시차 포함)을 끄거나 줄이는 방법이 필요할 수 있습니다. 접근성을 위해 적절하게 설계 및 개발되지 않은 웹 사이트는 미국에서만 수천만 명의 사람들이 은행 계좌를 확인하거나 청바지를 구매하는 것과 같은 일상적인 작업을 수행하지 못하게 할 수 있습니다. 이것이 접근성을 사후 고려가 아닌 일상 업무에 포함시키는 것이 중요한 이유입니다. 많은 접근성 문제는 디자인 단계에서 해결되어야 하지만 디자이너는 현재 사람들이 웹에 액세스하는 데 사용하는 기술과 직접 상호 작용하는 디자인을 만들 수 없습니다. 디자인을 코드로 변환하는 것은 개발자의 역할이며 올바르게 실행하면 사용자가 필요한 경험을 얻을 수 있는지 여부를 결정할 수 있습니다. 코드는 우리 제품과 사용자 에이전트 사이의 이음매 레이어입니다. 브라우저, 키보드, 화면 판독기 등 대부분의 사람들이 알고 있는 일반적인 사용자 에이전트가 많이 있습니다. 그러나 다른 많은 기술도 있으며 매일 더 많은 기술이 개발되고 있습니다. 여기에서 Robust 의 WCAG(웹 콘텐츠 접근성 지침) 원칙이 적용 됩니다. 우리가 생산하는 제품이 "보조 기술을 포함하여 현재 및 미래의 사용자 에이전트와의 호환성을 극대화"하기 위해 따라야 하는 접근성 지침이 존재합니다. 그것은 본질적으로 그러한 기술의 제작자와의 계약입니다. 가이드라인에 따라 작성되는 우리 코드에 의존할 수 있다면 해당 코드와 함께 작동하도록 기술을 개발하는 방법을 알고 있는 것입니다. 해당 계약의 요구 사항을 충족하는지 확인하기 위해 무엇을 할 수 있습니까? 프로세스에 접근성 구축 UX, 디자이너 및 콘텐츠 제작자와 협업 개발자, 디자이너, 콘텐츠 제작자는 접근성에 대해 각기 다른 고려 사항을 가지고 있지만 같은 팀에 속해 있습니다. 이러한 역할 간의 협업을 위한 좋은 프로세스를 설정하면 제품의 접근성에 큰 영향을 미칠 수 있으며 해당 사람들이 작업을 더 쉽게 수행할 수 있습니다. 제품이 아직 디자인 단계에 있을 때 개발자가 디자이너와 동기화하도록 하면 접근성에 대한 초기 논의가 가능합니다. 지금은 예상되는 상호 작용에 대해 이야기하고 디자인에 대한 설명을 제공하며 잠재적인 접근성 문제를 드러낼 때입니다. 이 단계에서 디자이너는 디자인 이면의 추론을 전달할 수 있으며 개발자는 접근 가능한 방식으로 디자인을 구현할 수 있는 문제에 대한 통찰력을 제공할 수 있습니다. 콘텐츠 제작자와 협업 할 수 있는 좋은 시간이기도 합니다 . 개발자는 대체 텍스트 또는 아리아 레이블과 같은 속성을 포함해야 한다는 것을 알고 있을 수 있지만 콘텐츠 작성자는 이러한 속성에 포함된 콘텐츠가 사용자에게 유용할 수 있도록 도울 수 있습니다. 디자인 시스템 팀의 맥락에서 구독 팀의 콘텐츠 작성자가 특정 사용 사례에 대해 액세스 가능한 콘텐츠를 만드는 데 도움이 되는 문서를 작성할 수도 있습니다. 개발자, 디자이너 및 콘텐츠 제작자가 한 팀으로 작업하여 접근성 문제를 감지할 수 있는 또 다른 기회는 출시 전입니다. 프로젝트를 함께 검토하기 위해 페어링 세션을 예약 하면 접근성 요구 사항이 예상대로 충족되었는지 확인하고 코드가 프로덕션에 들어가기 전에 개선할 수 있습니다. Deque 팀은 당신이 좋은 모델을 찾고 있다면 디자이너/개발자 협업 에 대해 훌륭하게 이야기 합니다. 캡처 요구 사항 모든 개발자가 접근성의 전문가이거나 충족해야 하는 접근성 요구 사항을 알고 있는 것은 아닙니다. 기술 책임자이거나 요구 사항을 캡처할 다른 위치에 있는 경우 해당 요구 사항의 일부로 접근성을 포함합니다. 여기에는 예상되는 동작에 대한 설명, 관련 WCAG 지침 및 회사 지침에 대한 링크, 지침을 충족하기 위한 솔루션 및 테스트 단계가 포함될 수 있습니다. 이 정보를 JIRA 스토리(또는 이와 유사한 것)에 직접 배치하는 것도 개발 팀의 다른 구성원과 지식을 공유할 수 있는 좋은 기회입니다. 그것은 그들이 기대되는 것을 이해하는 데 도움이 될 것이며 미래에 접근 가능한 개발을 더 잘 이해하는 데 도움이 될 리소스에 노출될 것입니다. 무엇을 하든지 별도의 "접근성" 카드를 만들지 마십시오 . 접근성은 "있으면 좋은" 기능이 아니라 제품의 핵심 부분입니다. 별도의 접근성 카드를 만드는 것은 접근성을 백 버너에 배치하고 기술 부채를 늘리고 향후 팀을 위해 재작업을 야기할 수 있는 확실한 방법입니다. 접근성 문제는 여전히 가끔 발생할 수 있지만 접근성 문제를 해결하기 위해 접근성 버그 보고서 수신에 의존하지 마십시오. 이상적으로는 사용자에게 서비스를 제공하는 것이 우리가 접근 가능하게 개발하는 이유여야 하지만 접근 가능한 제품이 없으면 회사가 법적 조치 를 받을 수도 있습니다. 좋은 문서 작성 구성 요소의 예상 동작을 명확하게 정의하는 문서를 작성하면 현재 및 미래의 개발자가 해당 구성 요소를 액세스 가능하게 만드는 요소를 이해하는 데 도움이 될 수 있습니다. 이렇게 하면 개발자가 향후에 새로운 접근성 버그를 도입하는 것을 방지할 수 있습니다. 문서화해야 하는 접근성 고려 사항은 요구 사항으로 캡처되어야 하는 것과 유사합니다(예상 동작에 대한 설명, 관련 WCAG 및 회사 지침에 대한 링크, 테스트 단계). 이 문서는 README, Storybook 또는 회사의 디자인 시스템 문서에 있을 수 있습니다. Adobe Spectrum 및 REI Cedar 를 비롯한 많은 디자인 시스템 은 각 구성 요소에 대한 설명서에 직접 액세스 가능성을 추가합니다. 시험 접근성 테스트에 사용할 수 있는 도구가 그 어느 때보다 많습니다 . 사용할 도구를 결정하고 접근성 테스트 전략을 프로세스에 구축하면 더 많은 접근성 문제를 보다 일관되게 포착하는 데 도움이 됩니다. 도끼 접근성 린터와 같은 접근성 린터는 대체 텍스트 누락과 같이 쉽게 감지할 수 있는 접근성 문제를 코드 편집기에서 바로 알려주는 데 도움이 됩니다. ax 또는 Lighthouse 와 같은 브라우저 기반 테스트 도구 는 프로그래밍 방식으로 감지할 수 있는 대부분의 접근성 문제를 파악하는 데 유용합니다. 또한 파이프라인에 통합할 수 있는 axe-core/cli 및 pa11y 와 같은 단위 테스트 및 지속적인 통합 도구를 작성하는 데 도움이 되는 도구가 있습니다. 현재 사용 가능한 단일 자동화 도구는 모든 접근성 문제를 해결할 수 없습니다. 개발 프로세스의 여러 단계에서 도구와 기술을 조합하여 사용하면 팀에서 더 많은 문제를 감지하고 수정할 수 있습니다. 자동화된 테스트 도구의 한계는 접근성 문제의 30-50%를 차지하는 프로그래밍 방식으로 감지할 수 있는 문제에만 작동한다는 것입니다. 좋은 접근성 테스트 전략에는 수동 테스트도 포함됩니다. 최소한 개발자는 프로세스에 키보드 테스트를 통합해야 합니다. 스크린 리더 사용 방법을 알고 있다면 스크린 리더 테스트 를 수행하는 것도 가치가 있을 수 있습니다. 그러나 스크린 리더 테스트는 매일 스크린 리더를 사용하는 사람과 그렇지 않은 사람의 경험이 많이 다르다는 점을 이해하고 접근해야 합니다. 궁극적인 테스트는 제품이 장애가 있는 실제 사용자에게 작동하는지 여부입니다. 접근성 옹호 현재 모든 조직이 접근성에 초점을 맞춰야 하는 것은 아니라는 점을 잘 알고 있습니다. 그러나 접근성이 처음이건 전문가이건 관계없이 회사나 조직 내에서 여전히 접근성을 옹호 할 수 있는 방법이 많이 있습니다. 지식 공유 모든 사람은 가르칠 것이 있으므로 전문가가 아니더라도 알고 있는 내용을 공유하면 디지털 접근성 문제에 대한 관심을 불러일으키고 다른 사람들의 관심을 불러 일으켜 코드에 더 쉽게 접근할 수 있습니다. 접근성 문제에 대해 개발자와 짝을 이루는 시간을 갖는 것은 지식을 공유하는 좋은 방법입니다. 이 페어링 시간은 PR 검토의 일환으로 접근성을 처음 접하는 사람과 함께 하거나 더 많은 것을 배울 수 있는 방법으로 귀하보다 경험이 많은 사람과 함께 할 수 있습니다. PR 프로세스에 지식 공유를 구축하는 방법도 있습니다. pull 요청을 열 때 유효성 검사 단계에 접근성 테스트 단계를 포함해야 합니다. 이렇게 하면 접근성 지식이 없는 개발자가 구성 요소의 작동 방식을 이해하는 데 도움이 됩니다. 예상대로 작동하는지 불확실한 경우 페어링을 제안하는 것이 좋습니다. 다른 개발자의 PR을 검토하고 있다면 다른 사람들이 접근 가능한 코드 작성에 대해 더 많이 배울 수 있는 기회로 생각하십시오. 이것은 앞에서 언급한 페어링 세션을 시작하기에 좋은 또 다른 시간입니다. 발견한 문제를 보여주고 문제의 영향을 설명하며 문제 해결을 위한 적절한 기술을 배우도록 도울 수 있습니다. 마지막으로, 팀에 주간 데모 또는 학습 세션이 있는 경우 대규모 팀에 대한 접근성을 보여줄 수 있는 완벽한 기회입니다. 자세히 알아보기(또는 도움이 필요한 곳 ​​알아보기) 접근성이 처음인 경우 학습 여정을 어디에서 시작해야 하는지 파악하는 것이 어려울 수 있습니다. 공식 WCAG 가이드라인은 기술적으로 밀도가 높은 문서이며, 나중에 가이드가 되지만 읽어보려고 하는 것은 좋은 시작 방법이 아닙니다. 더 나은 접근 방식은 개념 을 이해하고 다른 개발자와 협력하여 솔루션을 구현하는 방법을 배우는 것으로 시작하는 것입니다. 접근성에 대한 기초가 이미 훌륭하다면 업계의 다른 많은 것들과 마찬가지로 끊임없이 진화하는 주제라는 사실을 깨달으십시오. 지난 몇 년 동안 새로운 테스트 도구 가 만들어졌으며 CSS 사양은 접근성을 염두에 두고 업데이트되었습니다 . 사용 가능한 최신 도구를 유지하면 개발자가 계속해서 가능한 한 액세스 가능한 제품을 만들 수 있습니다. 다행히 디지털 접근성이 필요한 관심을 받기 시작하면서 더 많은 리소스를 사용할 수 있게 되었습니다. 올해의 axe-con 컨퍼런스 는 최신 접근성 지식을 위한 풍부한 리소스였으며, 글로벌 접근성 인식의 날 에는 매년 수많은 이벤트가 있습니다. 결론 디지털 접근성의 중요성은 아무리 강조해도 지나치지 않습니다. 사람들을 디지털 경험에서 배제한다는 것은 많은 경험에서 완전히 배제된다는 것을 의미할 수 있습니다. 접근 가능한 솔루션을 구현하는 것이 항상 쉬운 것은 아니지만 개발자로서 직면하는 다른 많은 문제를 해결하는 것도 아니며 그만큼 중요합니다. 우리가 접근성을 염두에 두고 개발하는 이유는 사용자인 사람들에게 서비스를 제공하기 위한 것이며, 접근 가능한 디지털 경험을 위해 계속 노력하는 것은 개발자로서 우리가 가진 가장 중요한 역할 중 하나입니다.