'웹접근성'에 해당되는 글 2건

  1. 2017.05.17 웹접근성(web accessibility)에 대한 정의
  2. 2017.05.16 웹표준에 대해 알아보겠습니다.
IT이야기/입코딩2017. 5. 17. 09:31

이전에 웹표준에 대해서 포스팅하였습니다.


이번엔 웹접근성(web accessibility)에 대한 정의를 한번 알아보겠습니다.

제법 규모가 있는 사이트들은 일년에 몇회 이상 웹 접근성 컨설팅 업체를 통해서 검사를 받습니다.


W3C의 정의에 의하면 웹 표준성은 접근성, 사생활 보호, 보안, 국제화의 측면을 고려해야 합니다. 

이 중에 접근성을 흔히 '웹접근성'이라고 하고 웹 표준성과 함께 많이 언급되는 개념입니다. 

웹접근성은 장애 여부에 상관없이 누구나 원활하게 웹페이지를 이용할 수 있어야 한다는 것을 의미합니다. 

예를 들어 시각장애인의 경우 화면을 눈으로 볼 수 없기 때문에 그렇지 않은 사람과 같은 방식으로는 웹페이지를 이용할 수 없습니다. 

그래서 '스크린 리더'라는 별도의 소프트웨어를 컴퓨터에 설치해서 인터넷을 이용합니다. 

스크린 리더는 모니터에 비춰지는 내용을 인식해서 음성, 점자로 출력해주는 역할을 합니다. 

화면에 '메뉴'라는 텍스트가 있으면 이를 인식해서 '메뉴'라는 음성이 나오는 방식이라고 합니다. 

시각장애인은 이를 이용해 눈으로 보는 대신 소리로 들으면서 웹페이지에 담긴 정보를 이해할 수 있습니다. 

하지만 스크린 리더는 소프트웨어에 불과하므로 스스로 웹페이지의 내용을 분석해서 이건 무슨 내용이고 저건 무슨 내용이다라는 걸 이해할 수 없습니다. 

특히 이미지의 경우가 그렇습니다. '메뉴'라고 텍스트로 집어 넣지 않고 메뉴라고 그려진 이미지를 사용하면 비 시각 장애인의 눈에는 똑같이 메뉴라고 보이지만 소프트웨어 입장에서는 그저 이미지일 뿐입니다. 

그 이미지 안에 그려진 내용을 인식하는 것은 불가능합니다. 

그래서 되도록 이면 이미지를 사용하지 말고 소스 코드에 내용을 그대로 담는 것이 권장되며, 부득이하게 이미지를 사용할 경우 반드시 이 이미지가 어떤 내용인지 설명을 추가해야 합니다. 


<button>메뉴</button>

<img src="images/button.jpg" alt="메뉴 버튼" />


위와 같이 메뉴 버튼을 두 가지 방식으로 구현할 수 있습니다. 

윗줄은 <button> 태그를 이용해서 구현하는 방식이고 아래 줄은 버튼 모양의 이미지를 쓰는 방식입니다. 

둘 중 어느 방식을 쓰던 버튼의 기능은 그대로 구현할 수 있습니다. 하지만 되도록이면 윗줄의 방식을 쓰는것이 권장됩니다. 

이미 <button> 태그를 쓰고 있기 때문에 스크린 리더가 메뉴라는 텍스트가 담긴 '버튼'이라는 것을 사용자에게 올바르게 전달할 수 있기 때문입니다. 

하지만 부득이하게 이미지를 쓴다면 특히 버튼 특유의 회색 그라데이션을 견딜 수 없다면 alt라는 속성을 추가한 뒤 이 이미지가 무슨 이미지인지 설명하는 텍스트를 추가해주어야 합니다. 

이렇게 할 경우 비 시각 장애인의 눈에는 alt 속성에 쓰여진 '메뉴 버튼'이라는 텍스트는 볼 수 없습니다. 

하지만 스크린 리더는 이를 '메뉴 버튼'이라는 이미지로 인식해 사용자에게 정보를 전달하게 됩니다. 

이처럼 장애가 있는 경우에도 웹페이지를 원활하게 이용할 수 있도록 지켜야 하는 사항을 웹접근성이라고 합니다.



위키피디아에 등제된 웹접근성에서 고려해야 할 사항입니다.


시각: 실명, 색각 이상, 다양한 형태의 저시력을 포함한 시각 장애

운동성: 파킨슨병, 근육병, 뇌성마비, 뇌졸중과 같은 조건으로 인한 근육 속도 저하, 근육 제어 손실로 말미암아 손을 쓰기 어렵거나 쓸 수 없는 상태

청각: 청각 장애

발작: 깜박이는 효과나 시각적인 스트로보스코프를 통해 일어나는 뇌전증성 발작

인지: 문제 해결과 논리 능력, 집중력, 기억력에 문제가 있는 정신 지체 및 발달 장애, 학습 장애 (난독증, 난산증 등)



웹접근성 지침 한글번역본

자세한 웹접근성 지침에 관한 정보들이 있습니다.


네이버에서 '널리'라는 프로젝트의 일환으로 네이버 사옥 그린팩토리 2층에 '웹접근성 체험 부스'를 오픈했습니다. 

이 곳에 방문하면 누구나 무료로 실제 장애가 있는 경우 어떤 식으로 인터넷을 이용하는지 직접 체험해 볼 수 있다고 합니다.


널리 공식 홈페이지


웹접근성 연구소 아래에 사이트에 가입하고 들어가서, 코딩한 페이지가 접근성에 맞는지 문의할 수도 있더군요.

웹접근성 연구소


웹사이트는 모두가 사용할 수 있어야 합니다. 

별거 아닌거같아 보였는데 웹사이트를 만들려면 여러가지 고려해야 할 사항들이 많네요.



출처 : 나무위키, 위키피디아

Posted by Joseph514
IT이야기/입코딩2017. 5. 16. 17:25


-웹표준에 대해 알아보겠습니다.


웹개발을 하다보면, 웹표준이니 웹접근성이니 하는 말들을 인터넷에서 많이 사용하는데요. 

우선, 웹 표준이란 무엇인지 이 포스팅에서 한번 알아보겠습니다.

월드 와이드 웹의 측면을 서술하고 정의하는 공식 표준이나 다른 기술 규격을 가리키는 일반적인 용어입니다.

보통 인터넷을 이용할 때 같은 웹페이지라면 어느 브라우저를 사용하는지 여부에 상관없이 그 웹페이지가 똑같이 보이고 정상적으로 작동해야 함을 의미합니다. 

Acid 테스트를 통해서 웹 브라우저가 웹 표준을 준수하는지 테스트할 수 있습니다. 

W3C 웹표준 설명



이전에 엑티브x(Atcivex)항목에서 포스팅 하였던 데로 한국에서는 정부나 공공기관부터가 웹 표준을 무시하고 있습니다.


웹 사이트를 작성하는 데 중요도가 높아지고 있으며 웹 디자인, 개발과 관계가 있습니다. 

수많은 상호 의존성이 있는 표준들과 규격들 가운데 일부는 단지 월드 와이드 웹으로만 끝나는 것이 아니라, 인터넷의 관리 측면이기도 하며 이러한 표준들은 직간접적으로 웹 사이트, 웹 서비스 개발과 관리에 영향을 주고 있습니다. 

웹 표준을 완벽하게 지키려면 특정 브라우저에 의존하는 플러그인이나 코드를 완벽하게 제거해야 하는 것이 보통인데, 일반적인 브라우저에 공통적으로 제공되는 플러그인은 이 기준에서 예외가 되는 경우가 많습니다.

이러한 것들 모두 "웹 표준"이라고 부르지만 웹 표준으로 이동하는 것을 찬성하는 사람들은 사용성과 접근성에 직접 영향을 미치는 더 높은 수준의 표준에 초점을 두는 경향이 있습니다. 


더 넓은 뜻의 웹 표준은 아래를 이릅니다.


-W3C (World Wide Web Consortium) - 대표적으로 HTML과 CSS의 표준을 정한다.

-국제 인터넷 표준화 기구 (IETF)가 출판한 인터넷 표준 (STD) 문서

-국제 인터넷 표준화 기구 (IETF)가 출판한 RFC (Request for Comments) 문서

-국제표준화기구(ISO)가 출판한 표준들

-Ecma 인터내셔널 (이전 이름은 ECMA)이 출판한 표준들 - JavaScript 표준이 여기서 정해진다.

-유니코드 컨소시엄이 출판한 유니코드 표준과 다양한 유니코드 기술 보고서 (UTR)

-인터넷 할당 번호 기관 (IANA)이 운영하는 이름과 번호 레지스트리



-웹 표준이 중요한 이유는 무엇일까요?

산업표준이 왜 존재하는지, 도량형이 왜 존재하는지 생각해 보면 이유가 명확해집니다. 

산업현장에서 부품들의 표준화가 돼 있지 않으면 업체마다 서로 호환이 되지 않고, 같은 업체에서 생산하는 부품도 품질보장이 되질 않을 것입니다. 

웹 환경은 본질적으로 '통신'이기 때문에 더욱 더 표준화가 중요해집니다. 

비표준 '부품'이야 자기네 제품에만 독점적으로 사용할 거라면 크게 상관없지만 웹은 누가 어떤 장치를 어떤 방식으로 사용할지를 제공자가 통제할 수 없기 때문입니다.


2016년 기준으로 인터넷 사용 인구는 30억명을 훌쩍 넘어 갔습니다. 

사실상 전인류의 절반이 인터넷을 사용하고 있고 인터넷 트래픽의 거의 전부를 차지하는 게 웹 트래픽입니다. 

사용하는 사람이 많아지면 표준화는 반드시 해결해야 할 과제가 됩니다. 그것이 일개 개인의 프로젝트에서 시작되었든(월드 와이드 웹), 국제 연합 수준의 극대규모 프로젝트(미터법)였던 말입니다.


웹 표준이 없던 90년대 말 ~ 2000년대 초반에는 웹 사이트 개발자는 사실상 두 개의 사이트를 만들어야 했습니다. 

인터넷 익스플로러용과 넷스케이프용의 두 개로 말이죠. 

실질적으로는 각종 핵과 브라우저 판별 코드를 삽입해야 해서 3배의 노동이 들어갔다고 합니다. 

표준이 없으면 이렇게 더 많은 노동력과 시간이 듭니다. 사회 전체적인 비용이 증가하는 것입니다. 

시간과 예산이 빠듯한 상황에서 웹 개발자는 결국 하나만을 선택하고 나머지를 버릴 수밖에 없어지며 이는 정보 제공에 차별을 발생시킵니다.


인터넷에 정보는 차별없이 제공되어야 합니다. 


물론 이상과 현실은 다릅니다. 

드넓은 PC모니터 화면과 좁디좁은 스마트워치 화면에서 동일한 정보를 제공하는 건 말도 안 되는 소리이고 동영상 스트리밍 사이트가 맹인을 고려해야 한다는 말도 어불성설입니다. 

하지만 이상을 추구해야 하는 것은 맞습니다. 


즉 "이 사이트는 인터넷 익스플로러 6, 1024x768해상도에서만 이용하실 수 있습니다." 같은 말들은 횡포일 뿐입니다. 

본인이 갑이 아닌데도 불구하고 이런 횡포를 부린다면, 그건 장사하기 싫단 소리밖엔 안 됩니다. 


제가 처음 웹이랍시고 홈페이지를 만들어본게 2000년대 초반입니다.

지금와서 보면 포토샵이랑 나모웹에디터로 찍찍 그려서 제로보드 적용시켜 뚝딱 만들고 했었던게 기억나네요. 

그 당시에는 저처럼 웹표준이란 개념도 없이 자바스크립트로 도배하거나, 플래쉬로 도배된 사이트들도 많았습니다.

위에서 언급한데로, 어떤 해상도에 어떤 웹브라우저에서 최적화 되었습니다 라는 문구가 씌어진 사이트들이 많았습니다. 그리고 제 컴퓨터에서는 아주 잘 나오는데, 이게 학교 컴퓨터나 다른 사람들 피씨에서는 어긋나게 나오는 경우를 왕왕 보았습니다. 익스플로러에서만 나온다는 건, 윈도우 운영체제를 깔아야 한다는 전제로 하는데. 한국에서야 윈도우에 익스플로러 사용자들이 엄청나게 많고 예전엔 더 많았지만, 현재는 크롬 파이어폭스 사파리도 많은 점유율을 차지 하고 있습니다.


나무위키에 등재된 2000년도 초반의 웹표준을 무시한 홈페이지들의 특징을 말씀드려보겠습니다.


-대문이 단순히 '들어가기' 형태로 된 홈페이지들이 많았습니다. 

사이트에 관한 내용을 간단히 보여주는 오늘날의 대문과는 차이가 있었습니다. 

리뉴얼 전 NTX(구 엔젤하이로)나 사유화 사태 전 리그베다 위키의 대문도 개인 홈페이지로 출발하던 시절의 전통이 그대로 유지됐는지 이 방식을 쓰고 있었다고 합니다.

-프레임 구조를 채용한 홈페이지들이 많았습니다. 

지금은 CSS나 jQuery 등의 보급과 W3C의 프레임 구조 채용 지양 권고로 인해 프레임 구조를 채용하지 않는 추세이지만 그 당시에는 프레임 구조의 장점이 많았기 때문에 높은 확률로 프레임을 쓴 것입니다.

header, menu, main, footer 이런식으로 프레임을 나눠서 사용했던 기억이 나네요.

-배경음악을 깔아놓은 홈페이지들을 많이 볼 수 있었습니다. 

바로 앞의 '프레임 구조'의 특징을 활용해서 끊김없는 재생을 구현하면 금상첨화였습니다. 

당시 회선 환경상 MP3를 넣으면 용량의 압박이 심했던지라 MIDI가 대세였습니다. 

인터버드라는 사이트에서 대규모로 MIDI 음악 자료실을 제공해서 인기가 있었지만, 안타깝게도 2001년 가을을 즈음하여 저작권 문제로 문을 닫았습니다. 

나중에 WMA 같은 압축 스트리밍 파일이 보급돼 배경음악으로 쓰이기도 했습니다.

-알록달록한 글꼴 색상과 효과, 화려한 클립아트와 애니메이션 GIF 등이 많이 쓰였습니다. 

이러한 풍조는 웹표준 보급 이후 다소 사그라들었다고 합니다.

-표를 그릴 때 쓰는 <table> 태그로 디자인을 하는 홈페이지들이 있었습니다. 

아직 CSS가 보급되기 전인지라 지금은 어지간하면 CSS로 넣는 디자인적인 요소까지 당시에는 죄다 HTML 문서 안에 때려박을 수밖에 없었고 그래서 <table> 태그가 그나마 레이아웃 잡는데 안성맞춤이었던 태그였습니다. 

웹표준의 개념이 알려지고 HTML5와 CSS3가 널리 보급된 현재는 레이아웃용 태그와 <div> 태그를 쓰고 <table> 태그를 레이아웃용으로 쓰는 경우는 찾아보기 어려워졌습니다.

-초창기에는 자바 애플릿을 넣는 홈페이지들을 꽤 볼 수 있었습니다. 

하지만 자바 가상 머신이 필요하다는 문제점이 있었고 매크로미디어 플래시가 보급된 이후 점차적으로 자바 애플릿 중 일부가 플래시로 대체되었습니다. 

물론 플래시를 보기 위해서도 매크로미디어 플래시 플레이어 플러그인을 깔아야 했다는 점은 똑같습니다. 

현재는 자바 애플릿이 이미 사양길로 들어선 상태고 플래시도 사정은 비슷합니다. 다만, 둘 다 HTML5로 대체할 수 있다고 합니다.

-게시판이나 방명록은 높은 확률로 홈페이지 서비스에서 함께 제공하는 게시판이 달려 있었습니다.


지금와서 아카이브로 박제된 90~2000년대 초반 홈페이지들을 보면 이질감이 느껴집니다.

그만큼 사람들은 웹 표준에 익숙해 졌기 때문 일수도 있겠죠.


민원24같은 전자정부 사이트는 갑의 요건을 일부 충족하기 때문에 아직도 영업이 가능한 면이 있지만 이것도 시대를 역행한다고 볼수 있죠. 내년까진 다 갈아엎는다고 들었습니다.


지금까지 웹표준에 대한 정의를 알아보았습니다.



출처 : 나무위키, 본인 생각

Posted by Joseph514