접근성을 향하여

금요일은 근무일의 끝입니다. 나쁜 소식은 항상 금요일 근무일이 끝나면 찾아옵니다.

당신은 곧 사무실을 떠나려고 합니다. 또 다른 조직 개편에 관한 새 편지가 방금 우편으로 도착했습니다.

고마워요 xxxx, yyy 오늘부터 신고하겠습니다 zzzz
...
그리고 Hugh의 팀은 장애가 있는 사람들이 우리 제품에 접근할 수 있도록 보장할 것입니다.

안 돼! 내가 왜 이런 자격이 있었나요? 내가 떠나길 바라는 걸까요? 고맙게도 열심히 일하고 다른 사람의 실수를 바로 잡으려고 노력하십시오. 이건 확실히 실패네요...

이것은 몇 년 전에 가용성이었습니다. 일부 불쌍한 영혼들에게는 UI를 "정리"하여 장애가 있는 사람들이 접근할 수 있도록 하는 작업이 주어졌습니다.

이것이 실제로 의미하는 바는 꽤 모호했습니다. 아마도 초점 표시기와 필드 탭을 볼 수 있고 대체 텍스트와 몇 가지 필드 설명이 있으면 애플리케이션에 액세스할 수 있는 것으로 간주될 것입니다.

그러나 갑자기 "벌레"가 눈사태의 속도로 증가하기 시작했습니다.

다양한 스크린 리더(공학과. 스크린 리더)와 브라우저는 완전히 다르게 동작했습니다.

사용자들은 앱을 사용할 수 없다고 불평했습니다.

한 곳에서 오류가 수정되자마자 다른 곳에서 또 다른 오류가 나타났습니다.

그리고 단순히 사용자 인터페이스 오류를 변경하고 수정하려면 엄청난 노력이 필요했습니다.

나는 거기에 있었다. 나는 살아남았지만 "성공"하지는 못했습니다. 기술적으로 많은 부분을 정리하고 많은 필드 설명과 역할을 추가하고 일정 수준의 규정 준수를 달성했지만 누구도 만족하지 않았습니다. 사용자들은 여전히 ​​애플리케이션을 탐색할 수 없다고 불평했습니다. 관리자는 계속되는 오류에 대해 여전히 불평했습니다. 엔지니어들은 모든 경우에 적용할 수 있는 "올바른" 솔루션이 명확하게 정의되지 않은 채 문제가 잘못 제기되었다고 불평했습니다.

접근성을 이해하는 과정에서 확실히 눈을 뜨게 만드는 순간이 있었습니다.
아마도 첫 번째는 완성된 제품 위에 접근성 기능을 추가하는 것이 어렵다는 인식이었을 것입니다. 그리고 그것이 엄청나게 어렵다고 관리자를 설득하는 것은 더욱 어렵습니다! 아니요, 단순히 "태그 몇 개 추가"만 하는 것이 아니라 UI가 제대로 작동합니다. 아니요, 이 작업은 XNUMX주 안에 완료할 수 없습니다. XNUMX개월도 충분하지 않습니다.
시각 장애인들이 실제로 우리 앱을 어떻게 사용하는지 직접 봤을 때 진실을 알게 되었습니다. 이는 오류 메시지를 보는 것과는 매우 다릅니다.

이 문제에 대해 몇 번이고 다시 언급하겠지만 사람들이 우리 앱을 어떻게 사용하는지에 대한 우리의 "가정"은 거의 모두 잘못되었습니다.

키 입력을 사용하여 복잡한 사용자 인터페이스 탐색 Tab/Shift+Tab – 이건 짜증나! 더 나은 것이 필요합니다. 키보드 단축키, 헤더.

UI를 변경할 때 집중력이 떨어지는 것은 큰 문제가 아니죠? 다시 생각해 봅시다. 이것은 엄청나게 혼란스럽습니다.

계속해서 한동안 다른 프로젝트를 진행하다가 복잡한 사용자 인터페이스와 명확한 설치를 갖춘 새 프로젝트를 시작하여 마침내 접근성을 확보했습니다.

그래서 우리는 한발 물러서서 어떻게 하면 이것을 다르게 구현하고 성공할 수 있는지, 그리고 프로세스를 덜 지루하게 만들 수 있는지 살펴보았습니다!

아주 빨리 우리는 몇 가지 결론에 도달했습니다.

1. 우리는 사용자 인터페이스를 개발하는 사람들이 aria 레이블/역할은 물론 구성 요소의 HTML 구조를 엉망으로 만드는 것을 원하지 않았습니다. 우리는 즉시 접근성을 구축할 수 있는 올바른 구성 요소를 제공해야 했습니다.
2. 접근성 == 사용 용이성 – 즉 이는 단순한 기술적인 도전이 아닙니다. 전체 디자인 프로세스를 변경하고 UI 디자인을 시작하기 전에 접근성을 고려하고 논의해야 했습니다. 사용자가 기능을 발견하는 방법, 탐색하는 방법, 키보드에서 마우스 오른쪽 버튼을 클릭하는 방법을 초기에 생각해야 합니다. 접근성은 디자인 프로세스의 필수적인 부분이어야 합니다. 일부 사용자의 경우 접근성은 단순한 애플리케이션의 외관 그 이상입니다.
3. 처음부터 우리는 시각 장애인 및 기타 장애가 있는 사용자로부터 애플리케이션 사용 용이성에 대한 피드백을 받고 싶었습니다.
4. 접근성 회귀를 포착할 수 있는 정말 좋은 방법이 필요했습니다.

글쎄요, 엔지니어링 관점에서 볼 때 첫 번째 부분은 아키텍처를 개발하고 구성 요소 라이브러리를 구현하는 것인 꽤 재미있어 보였습니다. 그리고 실제로 그랬습니다.

한걸음 물러서서 바라보다 ARIA 예시 그리고 이것을 "적합" 문제가 아닌 디자인 문제로 생각하여 몇 가지 추상화를 도입했습니다. 구성 요소에는 '구조'(HTML 요소로 구성)와 '동작'(사용자와 상호 작용하는 방식)이 있습니다. 예를 들어, 아래 스니펫에는 순서가 지정되지 않은 간단한 목록이 있습니다. "행동"을 추가하면 해당 역할이 목록에 추가되어 목록처럼 작동하게 됩니다. 메뉴에 대해서도 동일한 작업을 수행합니다.

실제로 여기에는 역할뿐만 아니라 키보드 탐색을 위한 이벤트 핸들러도 추가되었습니다.

이게 더 깔끔해보이네요. 이들 사이를 깨끗하게 분리할 수 있다면 구조가 어떻게 생성되었는지는 중요하지 않으며 여기에 동작을 적용하고 접근성을 올바르게 얻을 수 있습니다.

다음에서 이 내용을 실제로 볼 수 있습니다. https://stardust-ui.github.io/react/ – UX 라이브러리 반응는 처음부터 접근성을 염두에 두고 설계 및 구현되었습니다.

두 번째 부분 - 설계에 대한 접근 방식과 프로세스를 변경하는 것은 처음에는 저를 두렵게 했습니다. 조직 변화를 추진하려는 하급 엔지니어가 항상 좋은 결과를 보이는 것은 아니지만 우리가 프로세스에 크게 기여한 가장 흥미로운 영역 중 하나였습니다. . 간단히 말해서 우리의 프로세스는 다음과 같습니다. 한 팀에서 새로운 기능을 개발한 다음 리더십 팀이 제안을 검토/반복한 다음 승인되면 일반적으로 설계가 엔지니어링 팀에 전달됩니다. 이 경우 엔지니어링 팀은 접근성 기능과 관련된 모든 문제를 해결하는 책임이 있었기 때문에 사실상 접근성 기능을 "소유"했습니다.

처음에는 접근성과 사용성이 불가분의 관계에 있다는 점과 이를 디자인 단계에서 설명해야 한다는 점을 설명하는 것이 꽤 어려운 작업이었습니다. 그렇지 않으면 일부 역할에 대한 큰 변화와 재정의로 이어질 수 있었습니다. 그러나 경영진과 주요 관계자의 지원을 받아 아이디어를 실행에 옮기고 경영진에게 제시하기 전에 디자인의 접근성과 유용성을 테스트했습니다.

그리고 이 피드백은 모든 사람에게 매우 귀중했습니다. 사용자가 웹 애플리케이션과 상호 작용하는 방식에 대한 지식 공유/커뮤니케이션 연습으로서 환상적이었고, UI가 구축되기 전에 수많은 UI 문제 영역을 식별했으며, 현재 개발 팀은 훨씬 더 나은 사양을 보유하고 있습니다. 시각적인 측면뿐만 아니라 디자인의 행동적인 측면도 포함됩니다. 실제 토론은 기술적 측면과 상호 작용에 관한 재미있고 활기차고 열정적인 토론입니다.

이러한(또는 후속) 회의에서 시각 장애인 및 장애인 사용자가 있었다면 이 작업을 더 잘 수행할 수 있었습니다. 이를 구성하기가 어려웠지만 이제는 초기에 실행 흐름을 확인하기 위해 외부 테스트를 제공하는 현지 시각 장애인 조직 및 회사와 협력하고 있습니다. 개발 - 구성 요소 및 실행 흐름 수준 모두에서.

이제 엔지니어는 상당히 상세한 사양, 구현에 사용할 수 있는 구성 요소 및 실행 흐름을 검증하는 방법을 갖게 되었습니다. 경험을 통해 우리가 배운 것 중 하나는 우리가 줄곧 놓치고 있던 것, 즉 회귀를 멈출 수 있는 방법입니다. 마찬가지로 사람들은 통합 또는 엔드 투 엔드 테스트를 사용하여 기능을 테스트할 수 있으며, 이를 통해 시각적 및 행동적 상호 작용 및 실행 흐름의 변화를 감지해야 합니다.

시각적 회귀를 결정하는 것은 상당히 정의된 작업이므로 키보드로 탐색할 때 초점이 표시되는지 확인하는 것 외에 프로세스에 추가할 수 있는 작업이 거의 없습니다. 더 흥미로운 점은 접근성 작업을 위한 비교적 새로운 두 가지 기술입니다.

1. 접근성 통계 문제를 식별하기 위해 브라우저와 빌드/테스트 주기의 일부로 실행할 수 있는 도구 세트입니다.
2. 화면 판독기가 올바르게 작동하는지 확인하는 것은 특히 어려운 작업이었습니다. 액세스 기능이 도입되면서 접근성 DOM, 마침내 시각적 테스트에서와 마찬가지로 앱의 접근성 스냅샷을 찍어 회귀 테스트를 수행할 수 있게 되었습니다.

그래서 이야기의 두 번째 부분에서는 HTML 코드 편집에서 더 높은 수준의 추상화 작업으로 이동하고 디자인 개발 프로세스를 변경하고 철저한 테스트를 도입했습니다. 새로운 프로세스, 새로운 기술, 새로운 수준의 추상화로 인해 접근성 환경과 이 공간에서 작업하는 것이 무엇을 의미하는지 완전히 바뀌었습니다.
그러나 이것은 시작일뿐입니다.

다음 "이해"는 시각 장애인이 최첨단 기술을 주도하고 있다는 것입니다. 앞서 설명한 변화로부터 가장 큰 혜택을 받는 사람은 시각 장애인일 뿐만 아니라 ML/AI를 통해 새로운 접근 방식과 아이디어가 가능하다는 것입니다. 예를 들어 몰입형 리더(Immersive Reader) 기술을 사용하면 사용자는 텍스트를 보다 쉽고 명확하게 표현할 수 있습니다. 소리내어 읽을 수 있고, 문장 구조가 문법적으로 분류되며, 단어 의미까지 그래픽으로 표시됩니다. 이는 기존의 "접근 가능하게 만든다"는 사고방식에 전혀 맞지 않습니다. 이는 모든 사람에게 도움이 되는 사용성 기능입니다.

ML/AI는 완전히 새로운 방식의 상호 작용 및 작업을 가능하게 하며, 우리는 이 최첨단 여정의 다음 단계에 참여하게 된 것을 기쁘게 생각합니다. 혁신은 사고의 변화에 ​​의해 주도됩니다. 인류는 수천 년 동안 존재했고, 기계는 수백 년 동안 존재했으며, 웹사이트는 수십 년 동안 존재했으며, 스마트폰은 더욱이 기술이 사람에게 적응해야 하며, 그 반대는 아닙니다.

PS 이 기사는 원본과 약간의 차이가 있는 내용으로 번역되었습니다. 이 기사의 공동 저자로서 나는 Hugh의 이러한 여담에 동의했습니다.

등록된 사용자만 설문 조사에 참여할 수 있습니다. 로그인제발

애플리케이션의 접근성에 주의를 기울이시나요?

• Да

• 아니

• 앱 접근성에 대해 처음 들어봤습니다.

17명의 사용자가 투표했습니다. 5명의 사용자가 기권했습니다.

출처 : habr.com