기본 콘텐츠로 건너뛰기

웹 접근성 공동 워크숍에 다녀와서

엊그제(4월 8일) 한국정보화진흥원, W3C WAI 가 주관한 웹 접근성 공동 워크숍에 다녀왔습니다.

한 2년 전까지만해도 장애인차별금지법이 제정되고, 우리나라에서도 웹 접근성에 대한 논의가 한창일때 저도 사용성 테스팅과 밀접하게 연관된 웹 접근성에 관심을 가지고 열심히 공부를 하기도 했었지만 별반 달라지지 않는 개발 환경에 염증을 느끼고 등한시하고 있다가 이번에는 웹 접근성 교육 및 대외협력 분과의장이신 Shawn Lawton Henry 님과 웹 접근성 평가 및 수정도구 분과의장이신 Shadi Abou-Zahra 님이 직접 발표하신다고 해서 오랜만에 룰루랄라 다녀오게 되었습니다.

무엇보다 그 비싸다는 동시 통역이 제공되어서 부담 없이 다녀올 수 있었습니다. 머.. 동시 통역이 꼭 좋은건 아니지만 말입니다.

어쨌든 2시간의 짧은 발표였지만 저에게는 정말 좋은 시간이었습니다.

발표 내용 전체를 자세하게 소개해드리기는 제 깜냥이 미천하고 몇가지 알게 된 사실에 대해 간단하게 소개해 드리겠습니다.

우선 웹 접근성에 제가 모르던 가이드라인이 더 있더군요.

웹 접근성에는 가이드라인이 3가지가 있습니다. 하나는 우리가 익히 알고 있는 컨텐츠에 대한 가이드라인으로 WCAG라고 합니다. 현재 버전은 2.0이고 이번에 알게 된 사실은 이것이 ISO/IEC 40500:2012로 제정되었더군요. 전 이 표준으로 제정되었다는 것이 대단히 고문적이라고 생각합니다.

이 가이드라인과 관련해서 국내에는 KWCAG라는 별도의 가이드라인이 있는데, 어떤 분이 이렇게 나라마다 별도의 가이드라인이 있는 것에 어떻게 생각하냐는 질문에 단호히 No 라고 답하시더군요. 저도 동일한 생각입니다. 더구나 이제는 국제 표준까지 마련된 상황이라면 국내에서도 웹 서비스 개발 시 이러한 표준 준수에 좀 더 관심을 기울여야 한다고 봅니다.

가까운 중국이나 일본도 현재는 WCAG 준수로 나가고 있다고 합니다.

두번째 가이드라인은 개발자를 위한 ATAG라는 가이드라인입니다. 이것은 개발 도구에 대한 가이드라인으로 개발 도구가 갖춰야 할 항목들이 제시되어 있습니다.

세번째 가이드라인은 사용자 에이전트를 위한 UAAG라는 가이드라인입니다. 이것은 스크린 리더 같은 보조 도구들이 갖춰야 할 항목들이 제시되어 있습니다.

이렇게 세개의 가이드라인을 소개 받고 나니 드는 생각이 잠깐~~ 개발자, 사용자, 컨텐츠는 있는데.. 그럼 테스터는?

그래서 질문을 했더니 테스터를 위한 가이드라인의 필요성에 대해 알고 있고, 현재 작업중이라고 합니다.

웹 접근성 평가를 위한 가이드라인이 현재 작업중이고 명칭은 WCAG-EM이라고 합니다. 이 가이드가 완성되기 전까지는 WCAG를 참고해서 테스트를 진행하라고 하더군요.

테스트 도구는 올해 가을 쯤에 최신의 내용으로 업데이트 될 예정이라고 합니다.

이외에도 WAI-ARIA와 INDIE UI에 대한 소개가 있었습니다.

역시 잠깐이라도 공부에 손을 놓으면 따라잡기 힘들다는 것을 느꼈습니다.

짧은 시간이었지만 웹 접근성에 관한 많은 내용이 바뀌어 있었습니다.

특히 HTML5의 완성도가 더 높아져 있더군요.

아.. 그리고 모바일가 관련된 가이드도 추가될 예정이라고 합니다.

역시 모바일 플랫폼이 빠르게 PC 플랫폼을 밀어내고 있는 것 같습니다.

그리고 두분 모두 이러한 웹 접근성을 제대로 구현하기 위해서는 개발 초기부터 계획을 세워서 구축해야하고 개발 초기부터 테스트를 철저히 수행해야한다고 강조하셔서 저는 좋았습니다.

배워야 할 것도 많고 알아야 할 것도 많고 다녀오고 나서 마음이 참 무거워지는 걸 느꼈습니다.

댓글

이 블로그의 인기 게시물

쪼끔 신기한 BSW 에어프라이어 BS-1714F

예전에 필립스에서 에어프라이어가 나와서 유행했던 적이 있습니다.
하지만 뭔가 믿음직스럽지 않은 광고와 비싼 가격때문에 관심을 끊고 살아왔었는데..
얼마전 뉴스를 보니 카피 제품이 많아지면서 가격이 꽤 많이 싸진걸 알게 되었습니다.
그냥 저냥 사용할만한 수준의 제품이 대략 6만원대의 가격이더군요..
그래서 그냥 한번 질러봤습니다.
솔직히 가정에서 튀김을 하기는 정말 번거롭습니다. 위험하기도 하고요..
가장 골 아픈 것은 기름 처리입니다. 버리는 것도 귀찮지만 기름 솥 닦는 것은 하신 분들은 다 아시죠. ㅠㅠ
그래서 튀김이 너무 먹고 싶어서 질렀습니다.
나가서 사먹어도 되지만.. 사먹는 것보다 해먹고 싶어서..
저는 BSW의 BS-1714F라는 모델을 이마트에서 구매해봤습니다. 대충 보니 이게 이마트의 PB 상품 같더군요..
상품이 오자마자 바로 도전해봤습니다.
우선 포크 커틀릿을 도전해봤는데.. 음.. 실제 기름에 튀긴것과 같은 색감은 나오지 않지만, 식감은 꽤 비슷합니다. 바삭 바삭 담백합니다...오~~
군고구마도 해봤는데.. 까맣게 탄 것과 같은 비주얼은 안나오지만 맛있습니다.
수제 감자 스틱은 잘 안되더라구요..
가장 최고의 요리는 당연히 삽겹살.. 정말.. 하아.. 최고입니다.
보니까 이게 오븐과 건조기를 약간 합친 느낌입니다.
집에 광파 오븐이 있으신 분은 굳이 구매를 안하셔도 될 듯 하지만.. 광파 오븐보다는 사용이나 관리가 꽤 쉽습니다.
다만 최대 단점이 전기입니다.
200도 기준으로 순간 1.7에서 2킬로와트 정도의 전력을 먹습니다.
대부분의 요리는 180도에서 200도 온도로 15분에서 20분 정도의 시간이 필요한데.. 대충 세탁기 돌리는 정도의 전기가 들어갑니다.
전기 걱정 안하시는 분은 자주 드실 것 아니면 괜찮은 선택인것 같지만 자주 해드시거나 전기 요금이 부담스러우신 분들은 한번 더 고민해 보셔야 할 듯 합니다. 전기 꽤 많이 먹습니다. (어쩌면 당연한 것이지요..)
그리고 진짜 튀김이 되는건 아닙니다. 겉부분을 완전히 건조시킨되 굽는 …

매우 매우 매우 실망스러운 레일플러스 모바일 교통카드

우리 나라에서 버스나 지하철 같은 교통 수단을 이용하는 대부분의 사람들은 티머니와 같은 선불교통카드나 카드사와 연계된 후불교통카드를 쓰는 경우가 거의 대부분일 것입니다.

저도 현금으로 지하철이나 버스를 이용해본지가 언제인지 기억이 가물가물 합니다. (최근에는 현금을 들고 다닐 필요가 거의 없긴 하죠. 그러다보니 가끔 지방에 가서 카드가 안되는 가게나 주차장 등에서 난감하기도 하고요..)

그런데, 이런 카드 말고 스마트폰으로 교통 수단을 이용하는 사람들도 있습니다.

우리 나라에서 스마트폰으로 교통 수단을 이용하는 것은 심카드를 기반으로 구현된 기술로 문제는 해외 단말은 이 기능을 지원하지 않는 다는 것입니다.

해외 단말들이 이와 같은 기능을 구현하기 위해서는 HCE 라는 방식이 필요한데.. 이런 방식으로 결제 시스템을 구현은 할 수 없지만 지금까지는 이 기술로 구현된 사례가 없었는데, 얼마전 코레일에서 레일플러스 모바일 교통카드를 HCE 로 구현하여 서비스를 시작했습니다.

이로서 해외 단말을 사용하는 사람들도 스마트폰으로 버스나 지하철과 같은 교통수단을 이용할 수 있게 될것이라고 환호했습니다만, 실상은 그렇지 않다고 볼 수 있습니다.

저는 넥서스 5X 사용자로 심카드를 기반으로 하는 결제 시스템을 쓸 수 없었기 때문에 저도 코레일에서 저 서비스를 내놓았을 때 기대에 부풀어서 나오자마자 바로 설치해봤습니다. 처음 서비스 시작한 시점이 8월이었는데, 그 때에는 안드로이드 8.0을 지원하지 않아서 서비스는 시작되었지만 사용할 수 없었습니다.

그러다가, 9월 업데이트로 안드로읻 8.0(오레오)에서도 해당 앱이 정상적으로 동작하게 되어서 한번 사용해 본 소감을 남깁니다.

우선 현재 시점으로 해당 서비스를 이용하는 방법은 크게 2가지입니다.

하나는 레일플러스 모바일 교통카드 앱을 설치하여 이용하는 방법이고, 다른 하나는 신한 판(앱카드)를 설치하여 이용하는 방법입니다.

카드 종류는 선불과 후불 2가지 종류가 있는데, 레일플러스 모바일 교통카드 앱은 2가지를 모두 지원하고…

테스트 케이스와 체크리스트의 차이가 뭐여?

테스트 실무에서 가장 혼돈되어 사용되는 용어 중 하나가 테스트 케이스와 체크리스트입니다.

많은 경우 체크리스트를 테스트 케이스로 사용하는 경우가 많습니다.

실제로 인터넷 커뮤니티나 블로그, ISO, IEEE, ISTQB 등등을 검색해보시면 테스트 케이스와 체크리스트에 대한 구분이 다 제각각입니다.

각각에 대한 정의가 다 제각각입니다.

사정이 이러하다보니 많은 사람들이 테스트 케이스와 체크리스트를 잘 구분하지 못하고 혼동해서 사용하는 경우가 많습니다.

물과 기름처럼 테스트 케이스와 체크리스트를 정확하게 구분할 수는 없겠지만..

ISTQB를 기준으로 말씀드리면 설계 기법을 통해 도출된 것은 테스트 케이스 그렇지 않은 것은 체크리스트라고 생각하시면 쉽습니다.

예를 들면 아래는 결정 테이블 테스팅 기법을 통해 도출된 테스트 케이스의 예제입니다.



실제 테스트 케이스는 위보다 복잡하겠지만 어쨌든 얘기하고 싶은 것은 위와 같이 설계 기법을 통해서 도출된 것은 테스트 케이스라고 합니다.

그런데 딱 보시면 아시겠지만 실제 테스트에서는 저 정도로는 테스트 커버리지를 충분히 만족했다고 얘기하기 힘듭니다.

그렇습니다.

어떤 분들은 테스트 케이스가 전가의 보도, 은 총알 쯤으로 생각하시는데..

테스트 케이스는 일종의 마지노 선이라고 보시면 됩니다.

최소한 제품을 테스트 할때 이정도는 해줘야 한다는 최후의 방어선 정도라고 보시면 됩니다.

전쟁에서 최후의 방어선은 물러설 수 없는 마지막 보루입니다.

하지만 최후의 방어선만 지킨다고 전쟁에서 승리할 수는 없습니다.

프랑스는 마지노 요새만 믿고 있다가 독일에게 깔끔하게 발렸던 과거가 있지요.

전쟁에서 승리하려면 앞으로 나가야하고 치밀한 전략과 전술이 뒷받침 되어야 합니다.

더 높은 커버리지를 도달하고, 충분히 좋은 테스트가 수행되려면 테스트 케이스는 기본이 되어야 하고 거기에 더해서 체크리스트가 따라와 줘야 합니다.

이러한 체크리스트는 팀의 경험과 과거 프로젝트의 데이터를 통해서 도출되어야 합니다.

위와 같은 테스트 케이스에 추가적으로 …