디자인 와이어프레임을 액세스 가능한 HTML/CSS로 변환

이 기사는 웹사이트와 모바일 앱에 액세스할 수 있도록 도와준 Deque의 친애하는 친구들의 도움을 받았습니다. 감사합니다!

너무 자주, 접근성은 사용자 인터페이스를 생성할 때 디자이너의 마음을 넘어서지 않습니다. 디자인 단계에서 접근성 고려 사항을 간과하면 웹 사이트나 애플리케이션으로 흘러 들어가 사용자에게 큰 영향을 미칠 수 있습니다. 사용성 테스트, 프로토타입 생성, 액세스 가능한 패턴 라이브러리 채택 또는 와이어프레임에 주석 달기 등 설계자는 액세스 가능성을 워크플로에 통합해야 합니다. 접근성 결함을 찾기 위해 QA 엔지니어에게 과부하를 주는 대신, 처음부터 접근성을 생각하거나 "왼쪽으로 이동"하면 제작하는 콘텐츠에 엄청난 긍정적인 영향을 미칠 수 있습니다.

왼쪽으로 이동

개발 프로세스의 여러 단계에서 결함 수정 비용의 변화를 보여주는 많은 연구가 있습니다. 설계 단계에서 결함을 수정하는 비용이 1배인 것을 기준으로 본 연구에서는 구현 시 6배, 코드 커밋 후 테스트 시 15배, 결함이 발생한 후 적발되면 최대 100배까지 비용 차이가 발생함을 보여줍니다. 생산에. NIST의 연구에 따르면 결함 수정 비용은 통합 테스트 중에 10배, 시스템 테스트 중에 15배이지만 프로덕션에서는 30배에 불과합니다.[^2] 조직의 실제 비용이 얼마이든 간에 한 가지 확실한 것은 설계에서 결함을 포착하고 개발 단계는 프로세스의 후반부보다 훨씬 저렴합니다.

Deque는 20년간의 접근성 테스트를 통해 데이터를 수집했습니다. 데이터에 따르면 웹 응용 프로그램이 복잡해짐에 따라 지난 5년 동안 본 경향은 페이지당 결함 수가 페이지당 30~50개로 꾸준히 증가하고 있다는 것입니다. 이러한 결함 번호는 종종 기능적 결함 비율을 축소하고 접근성 테스트를 이동하고 프로세스에서 가능한 한 왼쪽으로 수정하는 가치를 증폭시킵니다.

약 70%의 접근성 결함은 설계 및 개발 프로세스 동안 자동화 및 안내 테스트의 적절한 조합을 통해 피할 수 있습니다.

"

이 문서는 이를 달성할 수 있는 방법에 대한 개요를 제공하는 것을 목표로 합니다.

디자인 단계

주석

주석은 구현자에게 의도를 알리기 위해 디자인에 추가된 텍스트 또는 그래픽 설명입니다. 색상 및 글꼴 크기와 같은 항목에 주석을 추가하는 디자이너와 마찬가지로 접근성 정보도 디자인에 전달되어야 합니다. 간단한 오디오 플레이어 위젯을 살펴보고 어떤 종류의 주석이 필요한지 평가해 보겠습니다.

오디오 플레이어는 세 가지 컨트롤로 구성됩니다.

1. 이전 트랙으로 이동하는 컨트롤(해당되는 경우)
2. 현재 재생 중인 오디오 트랙을 재생 및 일시 중지하는 컨트롤
3. 다음 트랙으로 이동하는 컨트롤(해당되는 경우)

이름, 역할 및 상태

구성 요소의 액세스 가능한 이름은 보조 기술 사용자가 해당 구성 요소와 상호 작용할 때 어떤 정보를 받을지 결정합니다. 각 오디오 플레이어 컨트롤에 주석을 추가하는 것은 매우 중요합니다. 시각적으로 텍스트 콘텐츠 없이 아이콘만으로 표시되기 때문입니다. 즉, "이전 트랙", "일시 중지" 및 "다음 트랙"이라는 액세스 가능한 이름으로 3개의 컨트롤에 주석을 다는 것을 의미합니다.

다음으로 이 3가지 컨트롤 각각의 목적 에 대해 생각하고 싶습니다. 오디오 플레이어 작업을 수행하는 클릭 가능한 요소이므로 여기에서 분명한 역할 선택은 "버튼"입니다. 이것은 설계를 통해 가정해야 하는 것이 아니라 구현자가 이 의미 체계 정보를 컨트롤에 추가하도록 설계자가 주석을 달아야 하는 것입니다. 처음부터 역할을 매핑하면 구현이 이미 수행된 후 돌아가서 컨트롤에 추가할 필요가 없습니다.

마지막으로, 디자이너는 마우스를 가져갔을 때 컨트롤이 어떻게 표시되는지 매핑하는 것처럼 접근성 측면에서 위젯의 다양한 상태에 대해 생각해야 합니다. 오디오 플레이어의 경우 실제로 구현자를 위해 주석을 달아야 할 상태가 상당히 많습니다. "이전 트랙" 버튼부터 시작하여 재생할 이전 트랙이 없으면 비활성화해야 한다는 것을 알고 있습니다. 재생/일시 중지 버튼은 재생 상태와 일시 중지 상태 사이에서 오디오 플레이어를 전환해야 합니다. 즉, 액세스 가능한 이름이 해당 상태와 일치해야 함을 주석으로 표시해야 합니다. 버튼의 액세스 가능한 이름은 오디오가 재생 중일 때 "일시 중지"이고 오디오가 일시 중지될 때 "재생"이어야 합니다. "다음 트랙" 버튼의 경우 다음 트랙이 없을 때 비활성화되어야 한다는 사실을 주석으로 표시해야 합니다. 마지막으로 각 버튼에 대한 호버 및 포커스 상태에 주석을 달아 키보드 사용자가 오디오 플레이어에서 현재 포커스된 컨트롤을 시각적으로 표시할 수 있도록 해야 합니다.

전체 구성 요소에 대한 상호 작용

첫 번째 트랙에 있을 때: "이전 트랙" 버튼 비활성화

마지막 트랙에 있을 때: "다음 트랙" 버튼 비활성화

재생할 때 "일시 중지" 버튼을 표시하고 "재생" 버튼을 숨깁니다.

재생하지 않을 때: "재생" 버튼을 표시하고 "일시 중지" 버튼을 숨깁니다.

"재생"을 클릭한 후 "일시 중지" 버튼에 초점을 맞춥니다.

"일시 중지"를 클릭한 후 "재생" 버튼에 초점을 맞춥니다.

사용성 테스트

연구원이 사용자에게 일련의 작업을 수행하고 행동을 분석하는 UX 연구 방법론인 사용성 테스트는 디자인 단계에서 매우 중요한 단계입니다. 사용성 테스트에서 수집한 정보는 디지털 사용자 경험을 형성하는 데 중요합니다. 장애가 있는 사용자를 대상으로 이 테스트를 수행하는 것은 팀에서 이러한 사용자가 자신이 만들고 있는 콘텐츠와 얼마나 쉽게 상호 작용할 수 있는지에 대한 아이디어를 얻을 수 있도록 해주기 때문에 매우 중요합니다. 기존 시스템에서 사용성 테스트를 수행하는 경우 참가자를 위해 매우 현실적인 시나리오를 설정할 수 있으며 이는 다양한 보조 기술에 의존하는 사용자에게 매우 좋습니다.

존재하지 않는 시스템에서 사용성 테스트를 수행하는 경우 설계 소프트웨어의 출력을 둘러싼 접근성 문제를 처리할 준비를 하십시오. 이러한 도구에서 출력되는 대화형 프로토타입은 종종 최종 제품이 브라우저나 OS 플랫폼에 있는 것과 매우 다릅니다. 또한 이러한 "기능적 프로토타입"은 일반적으로 액세스하기가 매우 어렵습니다. 가능하면 프로토타입 대신 사용할 수 있는 가까운 대안을 야외에서 찾으십시오. 그러면 참가자가 시스템과 상호 작용하는 방식에 대한 좋은 아이디어를 얻을 수 있습니다. 예를 들어, 새로운 모바일 탐색 구성 요소를 구축하는 경우 인터넷에서 기존 구성 요소를 찾아 사용성 테스트를 수행합니다. 이 대안에서 무엇이 효과가 있었는지 확인하고 개선해야 할 점을 배우십시오. 어느 쪽이든 항상 사용성 테스트 참가자의 장애에 따라 편의를 제공할 수 있도록 준비하십시오. 테스트가 장애물 없이 순조롭게 진행되도록 하면 참가자가 만족할 뿐만 아니라 더 짧은 시간에 더 많은 테스트를 통과할 수 있습니다.

패턴 라이브러리

패턴 라이브러리는 사용자 인터페이스 구성 요소의 모음이며 디자인과 개발 단계 모두에서 매우 유용합니다. 손끝에 충분한 UI 구성 요소 집합이 있으면 완전한 기능의 응용 프로그램을 훨씬 쉽게 구축할 수 있습니다. 디자이너의 경우 이러한 구성 요소를 사용하면 애플리케이션 전체에서 일관성을 유지하여 사용자의 전반적인 경험을 개선할 수 있습니다. 개발자의 경우 완전히 테스트되고 액세스 가능하며 재사용 가능한 구성 요소를 사용하면 고품질 콘텐츠를 신속하게 제작할 수 있습니다. 이러한 구성 요소는 응용 프로그램을 통해 여러 번 사용될 수 있으므로 접근성 측면에서 특별한 주의를 기울여야 합니다.

개발자 와 협력

컨퍼런스 및 밋업에서 동료 개발자 및 디자이너와 이야기하면서 디자이너와 개발자가 완전히 분리되어 작업하는 분할된 팀에 대해 자주 듣습니다. 개발자는 디자인 검토 회의와 같은 디자인 단계에 포함되어야 할 뿐만 아니라 디자이너도 개발 단계에 포함되어야 합니다.

액세스 가능한 멋진 콘텐츠를 만들려면 협업이 중요합니다.

"

종종 개발자는 디자인 구성 요소를 형성하거나 디자인 문제를 해결하기 위한 접근 방식을 전환하는 데 도움이 될 수 있는 구현 세부 정보를 알고 있습니다. 마찬가지로, 디자이너는 간격 및 특정 색상 사용과 같은 세부 지향적인 측면이 접근성에 큰 영향을 미칠 수 있기 때문에 접근 가능한 디자인 구현과 관련하여 개발자가 계속 확인하도록 도울 수 있습니다. 개발자가 디자인을 구현하는 동안 디자이너는 초점 표시, 탭 순서, 읽기 순서, 글꼴, 색상, 접근 가능한 이름 및 이미지의 대체 텍스트와 같은 것에 세심한 주의를 기울여야 합니다. 결국 개발자가 무시하면 이러한 놀라운 접근성 관련 주석이 모두 무슨 소용이 있기 때문입니까?

개발 단계

접근성 테스트 자동화

우리 개발자들은 워크플로의 특정 항목이 완전히 자동화될 수 있다는 아이디어를 좋아합니다. 고맙게도 사용할 수 있는 놀라운 접근성 자동화 라이브러리가 많이 있으므로 팀에서 이를 활용하여 지속 가능한 액세스 가능한 인터페이스를 생성해야 합니다. eslint-plugin-jsx-a11y와 같은 정적 분석 도구는 개발자가 코딩하는 동안 잠재적인 접근성 문제에 대해 경고하는 즉각적인 피드백을 제공할 수 있습니다. 개발자는 코드를 입력하는 즉시 이러한 경고를 표시하도록 텍스트 편집기를 설정하여 이러한 결함이 표시되는 즉시 실시간으로 포착할 수 있습니다.

axe-core와 같은 접근성 규칙 엔진은 거의 모든 프레임워크 또는 환경에 통합될 수 있으며 매우 일반적인 접근성 문제를 포착하는 데 도움이 될 수 있습니다. 전체 팀이 액세스 가능한 콘텐츠를 만들 수 있도록 하는 가장 좋은 방법은 이러한 유형의 도구를 CI(지속적 통합) 및 CD(지속적 전달) 파이프라인에 통합하는 것입니다. 접근성 관련 테스트 사례(단위 또는 종단 간) 작성은 또 다른 훌륭한 자동화 형태입니다. 우리 팀에서는 위의 모든 것을 구성하여 모든 접근성 자동화 테스트가 통과할 때까지 pull 요청을 병합할 수도 없습니다. 이것은 우리가 개발 서버에 도달하더라도 최소한의 접근성 결함을 보장할 수 있으며 확실히 프로덕션에 적용되지는 않을 것임을 의미합니다.

접근성 결함을 체계적으로 관리

접근성 문제는 보안 또는 기능 결함과 동일하게 취급되어야 합니다. 나머지 "정상" 워크로드와 함께 정기적으로 분류하고 우선 순위를 지정해야 합니다. 진행 상황을 측정하고 접근성 결함과 관련된 메트릭을 수집하는 것도 유용할 수 있습니다. 특히 팀이 접근성을 강화하기 시작한 경우에는 더욱 그렇습니다. 이것은 또한 시스템의 약점이나 병목 현상을 식별하는 데 도움이 될 수 있습니다. 팀이 스프린트 회고전(또는 이와 유사한 것)에 참여하는 경우 접근성이 화두가 되어야 합니다. 효과가 있는 것과 그렇지 않은 것에 대해 숙고하는 것은 건전한 연습이며 지속 가능한 접근성에 대한 팀의 전반적인 접근 방식을 향상시킬 수 있습니다.

이 멋진 도끼 베타 도구

우리는 테스트를 위한 훌륭한 출발점인 접근성 자동화에 대해 이야기했습니다. 그러나 필연적으로 인간은 완전한 접근성 테스트 범위를 얻기 위해 로봇이 떠나는 곳에서 픽업해야 합니다. 수동 테스트에는 W3C 웹 콘텐츠 접근성 지침(WCAG)뿐만 아니라 접근성에 대한 깊은 이해가 필요합니다. 도끼 베타 응용 프로그램은 접근성 전문가가 아니어도 수동 테스트를 통과하는 데 도움이 됩니다. 매우 간단한 질문을 하고 모든 어려운 작업을 수행하는 지능형 안내 테스트의 대규모 제품군이 있습니다!

우리가 항상 모든 것을 자동화하려고 노력한다는 점을 감안할 때 접근성 테스트는 완전히 자동화될 수 없으며 모든 기반을 다루는 인간의 두뇌가 필요하다는 주장에 회의적으로 반응할 수 있습니다. 그러나 이미지를 예로 들어 웹 페이지 컨텍스트에서 이미지가 제공하는 정보(있는 경우)를 살펴보겠습니다. 접근성 자동화 라이브러리는 이미지를 스캔하거나 처리하여 정보 의도를 도출할 수 없습니다. 기계 학습 알고리즘 이미지를 제공하고 해당 이미지에 있는 내용에 대한 완벽한 설명을 뱉어내더라도 페이지 컨텍스트에서 해당 이미지가 전달하는 내용을 알지 못합니다. 주어진 이미지가 전달하는 정보 또는 해당 이미지가 장식용으로만 사용되는지 여부는 전적으로 콘텐츠 작성자에게 달려 있습니다.

모든 것을 함께 묶기

개발 초기부터 접근성을 염두에 두면 소프트웨어 개발 수명 주기 후반에 이러한 고려 사항을 적용하는 것보다 접근성이 높은 콘텐츠를 훨씬 쉽게 만들 수 있습니다. 소프트웨어의 아이디어, 디자인 및 구현에 접근성을 포함하면 보다 지속 가능한 제품이 만들어집니다.

WCAG, ARIA, ARIA Authoring Practices 및 Stack Overflow와 같은 리소스를 활용하여 팀을 성공으로 이끌 수 있습니다. 접근성 자동화 라이브러리를 활용하고 지속적 통합 서버에 통합하여 접근성 결함이 소프트웨어에 침투하는 것을 방지합니다. 우리 팀은 자동 테스트와 수동 테스트 사이의 간격을 메우기 위해 열심히 노력했습니다. ax Beta를 사용해 보시기 바랍니다! 접근성 결함을 체계적으로 처리하면 애플리케이션에서 이러한 문제를 제거할 수 있을 뿐만 아니라 향후에도 문제가 재발하는 것을 방지할 수 있습니다.

이 정확한 주제에 대한 무료 워크숍에 참여하시겠습니까? 2개의 3시간 세션으로 분할될 예정인 Translating Design Wireframes Virtual Workshop에 등록하십시오.