디자인 와이어프레임을 접근성 있는 HTML/CSS로 옮기기

Translating Design Wireframes Into Accessible HTML/CSS — Smashing Magazine

 

Harris Schneiderman, 2020년 7월 21일

 

 

짧은 요약 → 접근성 있는 웹사이트나 앱을 만드는 가장 효율적인 방법은 개발 및 디자인 과정의 초기 단계에서부터 접근성 시험을 포함함으로써 "시프트 레프트(Shift left)"를 하는 것이다. 이 글에서 해리스는 와이어프레임 분석 및 디자인과 개발 단계에서 접근성을 위한 최적의 코딩 결정의 과정을 안내해줄 것이다.

 

너무나 자주, 접근성은 디자이너의 머릿속에 떠오르지 않는다.

유저 인터페이스를 만들어 낼 때 말이다. 디자인 단계에서 접근성에 대한 고려를 좌시하면 웹사이트나 애플리케이션까지 흘러들어가서 사용자들에가 커다란 영향을 줄 수가 있다. 사용성 시험이든지, 시제품 생성이라든지, 접근성 패턴 라이브러리를 도입한다든지, 또는 그냥 와이어프레임들에 주석을 달든지 간에 디자이너들은 작업 흐름에 접근성을 반드시 포함시켜야 한다. QA 엔지니어에게 접근성 결합들을 찾는 업무를 과중시키는 대신, 접근성을 처음부터 생각하든지, 아니면 "시프트 레프트"가 당신이 만들어 내는 컨텐츠에 엄청나게 긍정적인 영향을 끼칠 것이다.

 

시프트 레프트

개발 과정의 여러 단계에서 결함을 수정하는 비용의 변화를 보여주는 연구는 많이 있다. 디자인 단계에서 결함을 수정하는 비용을 1x 인수라고 기준을 잡은 이러한 연구들은, 개발 중에는 6x로 증가하고 코드가 커밋된 후 시험에는 15x, 그 결함이 생산까지 도달한 후 잡혔을 때에는 100x 만큼이나 높아진다는 비용 차이를 보여준다. NIST 연구는 결함 수정 비용이 통합 시험 동안에는 10x, 시스템 시험 동안에는 15x, 그러나 생산에서는 30x 밖에 안 된다고 추산한다. 당신의 조직의 실제 비용이 얼마인지에 상관 없이, 한 가지는 확실하다: 디자인과 개발 단계에서 결함을 잡는 것이 후처리에서 보다 몇 자리수는 비용이 덜 든다는 것이다.

 

데크(Deque)는 20년 동안의 접근성 시험에 대한 데이터를 조합했다. 그 데이터에 근거하여 지난 5년 간 우리가 봐온 양상은, 웹 애플리케이션들의 복잡성은 더 증가했고 한 페이지 당 결함들은 30~50 개 사이로 꾸준히 증가했다는 것이다. 이러한 결함의 숫자들은 다른 어떤 기능적 결함들의 비율도 작아 보이게 하고, 접근성 시험과 수정을 가능한한 그 과정의 아주 초기부터 하는 것의 가치를 증폭시킨다.

 

"접근성 결합들의 70%는 디자인과 개발 과정에서 자동화되고 유도된 시험의 적절한 조합을 통해 피할 수 있다."

 

이 글은 어떻게 이를 달성할 수 있는지에 대한 개요를 보여주는 것을 목표로 한다.

 

디자인 단계

주석

주석들은 실행 의도를 알리기 위해 디자인에 더해진 글자나 그래픽 설명들이다. 색상이나 글자 크기 같은 것들에 디자이너가 주석을 다는 것과 유사하게 접근성 정보도 반드시 디자인에 전달되어야 한다. 간단한 음원 재생 위젯에 뛰어들어 어떤 종류의 주석들이 필요할지 평가 해보자.

 

우리의 음원 재생은 세 가지 제어로 구성되어 있다:

 

01 앞 트랙(이 있을 때) 으로 가는 제어

02 현재 재생되고 있는 음원을 재생하거나 멈추는 제어

03 다음 트랙(이 있을 때) 으로 가는 제어

 

이름, 역할, 그리고 상태

접근성 있는 컴포넌트의 이름이 보조 기술 사용자가 그것과 상호작용 할 때 어떤 정보를 받게될 지를 결정할 것이다. 우리의 음원 재생 제어들 각각에 주석을 다는 것은 매우 중요한데 왜냐하면 시각적으로 그것들은 아이콘으로만 구현되고 글자 내용이 없기 때문이다. 이것은 우리가 이 세 제어들에 "이전 트랙", "멈춤", 그리고 "다음 트랙"과 같은 접근성 있는 이름들을 달을 것임을 의미한다.

 

그 다음, 우리는 이 세 제어들 각각의 목적에 대해 생각해야 한다. 이것들이 음원 재생 동작들을 수행하는 클릭 가능한 요소들이이므로 여기서 뻔한 역할의 선택은 "버튼" 이다. 이건 디자인 하면서 예상할 수 있는 것은 아니고 오히려 디자이너들이 실행하는 사람들한테 이 의미론적인 정보를 제어들에 더하라고 반드시 주석을 달아야 하는 것이다. 시작부터 역할들을 설계 해두는 것은 개발이 이미 시작된 후에 제어들로 돌아가서 더하는 수고를 덜어줄 것이다.

 

마지막으로 마우스를 올렸을 때 제어가 어떻게 보이는지를 디자이너들이 입안 하듯이, 본인의 위젯들의 다양한 상태들을 접근성 면에서 생각해야만 한다. 우리의 음원 재생기의 경우에서 실제로 개발자들을 위해 각주를 달을 꽤나 많은 상태들이 있다. "이전 트랙" 버튼에서 시작하면, 우리는 재생 할 앞 트랙이 없을 때 이것이 비활성화되어야 한다는 것을 안다. 재생/멈춤 버튼은 음원 재생기를 재생과 멈춤 상태 사이에서 전환시켜야 한다. 이 말은 우리가 그 상태에 매치될 필요가 있는 접근성 잇는 이름을 각주로 달아줄 필요가 있다는 뜻이다. 음원이 재생되고 있을 때 버튼의 접근성 있는 이름은 "멈춤" 이고 음원이 멈추어 있을 때는 "재생"이다. "다음 트랙"버튼에 대해서 우리는 다음 트랙이 없으면 비활성화되어야 한다는 사실을 각주에 달아야 한다. 끝으로 각 버튼의 커서 올림이나 포커스 상태에도 각주가 달려서 키보드 사용자가 오디오 재생기에서의 현재 포커스된 제어에 대한 시각적인 지침을 얻을 수 있어야 한다. 

 

전체 컴포넌트를 위한 상호작용

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

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

재생 중 "멈춤" 버튼 표시 및 "재생" 버튼 숨김

재생 중이 아닐 때 "재생" 버튼 표시 및 "멈춤" 버튼 숨기기

"재생" 클릭 후 "멈춤" 버튼에 포커스 하기

"멈춤" 클릭 후 "재생" 버튼에 포커스 하기

 

사용성 시험

사용성 시험, 연구원이 사용자에게 연속적으로 일을 시키고 그 행위를 분석하는 UX 연구 방식은 디자인 단계에 매우 중요한 단계이다. 사용성 시험에서 모여진 정보는 디지털 사용자 경험들의 틀을 잡는 데 필수적이다. 장애가 있는 사용자와 시험을 수행하는 것은 극도로 중요한데 왜냐하면 이런 사용자들이 자신들이 만들어 내는 내용과 얼마나 쉽게 상호작용할 수 있을지에 대해 당신의 팀이 아이디어를 얻을 수 있게 해주기 때문이다. 만약 기존 시스템에 사용성 테스를 하고 있는 중이라면 참여자들을 위한 아주 현실적인 시나리오를 설정할 수 있을 것이고 그것은 다양한 보조 기술들에 의존하고 있는 사용자들을 위해 매우 잘된 일이다.

 

존재하지 않는 시스템에 사용성 시험을 하고 있다면 디자인 소프트웨어의 결과를 둘러싼 접근성 도전들에 대해 감당할 준비를 하라. 이러한 도구들로부터 도출된 상호적인 시제품들은 종종 브라우저나 운영체체 플랫폼에 보이는 최종 제품과 극단적으로 다를 것이다. 이에 더해 이러한 "기증적인 시제품들"은 보통 극도로 접근성이 없다. 가능하다면 황야에서 시제품 대신 사용할 수 있는 가장 흡사한 대체품을 찾아라. 그것이 당신의 참여자들이 어떻게 당신의 시스템과 상호작용 할지에 대한 좋은 아이디어를 줄 수 있다. 예를 들어 새로운 모바일 내비게이션 컴포넌트를 만들고 있다면 인터넷에서 존재하는 것을 하나 찾아서 그걸로 사용성 시험을 한다. 이 대체품에서 무엇이 잘 작동했는지를 정하고 무엇이 향상될 필요가 있는지를 배워라. 어느 쪽이든지, 사용자들의 장애에 맞춰 사용성 시험에 대해 배려해줄 준비가 항상 되어 있어야 한다. 장애물 없이 시험이 순조롭게 진행되도록 확실히 하는 것은 당신의 참여자들을 기쁘게 할 뿐만아니라 더 많은 시험을 더 적은 시간 안에 해나가게 해줄 것이다.

 

패턴 라이브러리

패턴 라이브러리들은 사용자 인터페이스 컴포넌트들의 모음이고 디자인과 개발 단계 둘 다에서 엄청난 혜택을 준다. 충분한 UI 컴포넌트들의 세트를 손 끝에 두는 것은 완전히 기능하는 애플리케이션을 만드는 것을 훨씬 쉽게 한다. 디자이너를 위해서 이러한 컴포넌트들은 당신의 애플리케이션 전반적으로 일관성을 잘 유치하도록 도와주고 그것은 사용자들의 전반적인 경험을 향상시킨다. 개발자에게 완전시 시험이 끝났고, 접근성 있으며, 재사용 가능한 컴포넌트들은 높은 품질의 내용을 빠르게 생산하는 것을 도와준다. 이러한 컴포넌트들은 접근성 면에서 특별 관리 취급을 받아야 하는데 왜냐면 당신의 애플리케이션에서 아마도 수 차례에 걸쳐 사용될 것이기 때문이다.

 

개발자와 일하기

동료 개발자들 및 디자이너들과 컨퍼런스나 동호회 등에서 말하다 보면 디자이너와 개발자들이 서로 완전히 고립되어 일하는 나뉘어진 팀들에 대해 자주 듣는다. 디자인 검토 회의와 같은 디자인 단계에서 개발자들이 포함되어야 할뿐만 아니라 디자이너들도 개발 단계에 포함되어야 한다.

 

"경탄할만한 접근성 있는 내용을 만들어 내는 데에는 협업이 열쇠이다."

 

많은 경우 개발자들은 디자인 콤프들의 모양을 잡는데 도움을 주는 실행 세부 사항들에 대해 공유하기도 하고 디자인 문제를 해결하는 데에 심지어 중심축이 되기도 한다. 마찬가지로 디자이너들은 자신들의 디자인을 접근성 있게 실행시키는 데 있어 개발자들을 계속 감독하는 것으로 도와줄 수 있다. 왜냐하면 간격이나 특정 색상 사용 등 세부적인 것을 중시하는 면모가 접근성에 거대한 영향을 끼칠 수 있기 때문이다. 개발자들이 디자인을 실행시키는 동안 디자이너들은 포커스 지침, 탭 순서, 읽기 순서, 글자, 색상, 그리고 심지어 접근성 이름들이나 이미지 대체 글(알트 텍스트)과 같은 것에 주의를 기울여야 한다. 결국에 개발자가 이 모든 놀라운 접근성 관련 각주들을 무시해버린다면 그게 다 무슨 소용이겠는가?

 

개발 단계

접근성 시험 자동화

우리 개발자들은 우리의 작업 흐름에 있는 어떤 것들은 완전히 자동화될 수 있다는 아이디어를 너무 좋아한다. 고맙게도 많은 놀라운 접근성 자동화 라이브러리들이 이용 가능하고, 당신의 팀은 지속 가능한 접근성 있는 인터페이스들을 만들어 내는 것을 보조하는 데에 그것들을 이용해야 한다. eslint-plugin-jsx-a11y 같은 고정 분석 도구들은 개발자들이 코딩하는 중에 그들에게 잠재적인 접근성 문제들에 대해 즉시 피드백을 제공해줄 수 있다. 개발자들은 심지어 코드를 타이핑 해가면서 이러한 결함들이 뜰 때마다 잡아내어 경고들이 즉시 표시되도록 텍스트 에디터를 설정할 수도 있다. 

 

axe-core 와 같은 접근성 규칙 엔진들은 거의 모든 프레임워크나 혼경에 통합될 수 있고 많은 매우 흔한 접근성 문제들을 잡는 것을 도울 수 있다. 당신의 팀 전체가 접근성 있는 내용을 만들어 내는 것을 확실히 하기 위해 이러한 종류의 도구들을 CI(연속 통합) 및 CD(연속 전달) 관로에 통합하는 것이 하나의 좋은 방법이다. 접근성만을 위한 시험 경우들(유닛이나 양단간)을 기술하는 것은 또다른 대단한 자동화의 형태이다. 내 팀에서 우리는 위의 모든 것들의 조건을 설정하여, 어떠한 당김 요청도 우리의 모든 접근성 자동화 시험들을 통과하지 못하면 통합되지 못하게 했다. 이는 우리가 최소한의 접근성 결함도 우리의 데브 서버들에 닿지 못하게 하고 생산으로는 절대로 가지 못하게 보장할 수 있다는 뜻이다. 

 

접근성 결함들의 체계적인 관리

접근성 문제들은 보안이나 기능 결함들과 다르게 취급되지 않아야 한다. 나머지 "정상적인" 업무와 함께 정기적으로 분류되고 우선순위가 매겨져야 한다. 특히 당신의 팀이 막 접근성에 대해 알게되기 시작했다면, 접근성 결함들에게만 구체적인 진척 사항을 재거나 계량적 분석을 모으는 것도 유용할 수 있다. 이것은 또한 당신의 시스템의 약점이나 병목 구간을 밝혀내는 것을 도와줄 수 있다. 만약 당신의 팀이 스프린트 회고(또는 그와 같은 것)에 참여한다면 접근성도 토의 점이 되어야 한다. 무엇이 잘 되었고 안 되었는지를 반추해 보는 것은 건강한 습관이고 지속 가능한 접근성을 향한 당신의 팀의 전반적인 접근을 개선시키는 방향으로 나아가게 할 수 있다.

 

이 멋진 액스 베타 도구

접근성 자동화에 대해 얘기했었는데 이것은 시험을 위한 아주 좋은 시작점이다. 그러나 필수불가결하게, 사람은 접근성 시험을 다 다루기 위해 로봇이 손 떼어야 할 곳을 골라내어야 한다. 수동 시험은 접근성 만큼이나 W3C 웹 내용 접근성 가이드라인, 또는 "WCAG"에 대해서도 깊은 이해도를 요한다. 액스 베타 애플리케이션은 당신이 접근성 전문가가 아니더라도 접근성 시험을 해나갈 수 있게 보조해준다. 이것은 커다란 지능 안내 시험들 한 벌을 가지고 있는데 이것은 극도로 단순한 질문들을 하고 당신을 위해 모든 무거운 것들을 다 들어준다.

 

우리는 항상 모든 것을 자동화 하려는데에 매진한다는 것을 고려하면 접근성 시험은 완전히 자동화될 수 없고 모든 기본을 다룰 사람의 뇌를 필요로 한다는 주장에 회의적으로 반응할 사람도 있을 것이다. 그러나 이미지들을 예로 들면, 정보가 있다면 어떠한 정보를 웹페이지 맥락에서 제공하는가? 접근성 자동화 라이브러리는 이미지를 스캔하거난 처리함으로서 그 의도된 정보를 유추해낼 수 없다. 우리가 어떤 이미지에 머신 러닝 알고리듬을 주입하고 그것이 그 이미지에 대한 완벽한 묘사를 뱉어낼 수 있다고 해도 그 이미지가 그 페이지 맥락에서 뭘 전달하는 지를 알 수는 없다. 그 이미지가 순전히 꾸밈 목적으로만 사용되었을지라도 주어진 이미지에서 전달하고자 하는 정보는 온전히 그 내용의 저자에게 달려 있다.

 

모두 묶어서

소프트웨어 개발 라이프사이클에서 개발 시초부터 접근성을 염두에 두는 것은 이런 것들을 나중에 고려하는 것보다 접근성 있는 내용을 만들어 내는 것을 훨씬 쉽게 한다. 당신의 소프트웨어의 관념화, 디자인, 그리고 실행하면서 접근성이 구워져 들어가게 하는것은 더 지속가능한 제품을 만들어 낸다. 

 

WCAG, ARIA, ARIA Authoring Practices 그리고 Stack Overflow와 같은 자원들을 활용하여 당신의 팀이 성공하도록 마련하라. 접근성 자동화 라이브러리들을 이용하고 그것들을 연속 통합 서버들에 통합하여 접근성 결함들이 당신의 소프트웨어에 찾아들어갈 길을 차단하라. 우리 팀은 자동과 수동 시험 사이의 틈을 매우기 위해 열심히 일해왔다. 우린 당신이 꼭 액스 베타를 한 번 사용해 보길 바란다! 접근성 결함들이 체계적으로 다뤄질 수 있다면 당신의 애플리케이션들에 이러한 문제들을 제거할 수 있을뿐만아니라 향후에도 그것들이 다시 나타나는 것을 방지할 수 있다.