죠셉의 세상이야기

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

<button>메뉴</button>

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

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

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

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

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

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

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

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

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

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

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

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

청각: 청각 장애

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

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

웹접근성 지침 한글번역본

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

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

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

널리 공식 홈페이지

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

웹접근성 연구소

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

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

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

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

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

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

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

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

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

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

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

액티브x(ActiveX)가 내년(2018년) 공공 웹사이트에서는 자취를 감춘다고 합니다.

인터넷상에서 많이들 이야기하는 액티브x(ActiveX)란 무엇일까요?

나무위키에서 설명하는 액티브x의 정의입니다.

마이크로소프트에서 만든 COM(컴포넌트 오브젝트 모델)과 OLE(오브젝트 링킹 앤 임베딩) 기술 두 개를 합쳐서 이름을 새로 붙여준 것입니다. 

대부분 좁은 의미로 Internet Explorer에서 애드온으로 사용되는 ActiveX Control들을 말합니다. 

액티브X는 거대한 소프트웨어 프레임워크지만 대한민국에서는 '인터넷 익스플로러에 붙어서만 실행되는 윈도우 응용프로그램' 정도로 인식되는 것이 일반적입니다.

웹 브라우저의 역할을 넘어선 여러가지 기능을 자유롭게 수행할 수 있습니다. 

예를 들면 컴퓨터 내부에 파일을 생성한다든가 삭제 및 존재여부도 알 수 있고, 심지어는 컴퓨터 주인이 신경쓰지 않아도 실행도 가능합니다.

또한, 사용자가 관리자 권한을 허락해준다면 윈도우 폴더 내부에까지 파일을 생성할 수 있고, 레지스트리도 액티브엑스 오브젝트 맘대로 마음껏 수정할 수 있습니다. 이것은 웹 브라우저의 한계를 뛰어넘는 행동을 할 수 있습니다. 

개발자 입장에서는 굉장히 편리했습니다.

액티브X 기술이 대단히 편리한 기술임에는 틀림없었습니다. 

각종 다운로드 서비스, 게임 실행, 음악 재생 등 사용자의 인지 없이도 온갖 프로그램을 웹페이지 접속만으로 실행할 수 있었으며 한국이 일약 인터넷 강국으로 떠오르게 된 발판이기도 합니다. 

당시의 기술로는 액티브X가 없었다면 저런 것은 만들 수조차 없었거나 매우 느려서 쓸모가 없었습니다. 

90년대 당시 자바 애플릿을 채용한 곳도 있었으나 너무나 느렸기 때문에 사용자로부터 외면을 받았습니다.

하지만 이 기술은 한가지 큰 위험요소를 지니고 있었는데, 위에서도 써놓았듯 사용자의 간섭 없이도 자동으로 설치된다는 것은 곧 보안의 허점을 의미했습니다. 

사실 이미 IE5 때부터 자동으로 설치되는 것은 막혀 있었고, 설정만 한다면 아예 액티브X가 실행되지 않도록 할 수도 있었습니다. 

하지만 일단 설치된 후엔 멋대로 사용자의 컴퓨터를 주무를수 잇습니다. 

때문에 웹 페이지 접속만으로 온갖 악성 프로그램이 실행되는 것은 일상다반사였고 컴퓨터를 모르는 사람은 물론이고 아는 사람의 PC에까지 허구헌 날 바이러스와 악성코드가 창궐하기 일쑤였습니다.

이것은 단순히 액티브X만의 문제는 아니었고, 그것을 허용하게 하는 윈도우 운영체제와 IE의 허술함도 크게 기여했습니다.  이 문제는 결국 ActiveX의 자동실행, 설치 방지가 포함된 IE6에서 일부 해결되었고, 사용자의 관리자 권한을 제한하는 윈도우 비스타에 와서는 UAC 덕분에 이론상 거의 완벽하게 해결하게 되었는 줄 알았지만 현실은 컴맹들은 무조건 YES만 누르고, 심지어 UAC를 꺼버리는 만행까지도 저질렀습니다. 

결국 윈도우 10에 와서는 MS는 그냥 IE를 버리고 Edge를 만드는 방식으로 ActiveX(와 기타등등 산재한 문제들)를 해결하였습니다.

미운오리새끼 된 ‘액티브X’… 내년 공공 웹사이트서 자취 감춘다

원문보기

"

행자부·미래부 단계별 제거계획"이용 많은 민간 100대 사이트도세계 100대 웹사이트 수준 감축"

...

문재인 대통령이 발표한 ICT정책 중 하나인 공공기관 액티브엑스(이하 액티브X) 완전 폐지 공약이 실현될 전망이다. 행정자치부와 미래창조과학부가 단계별 제거 계획을 세우고 추진하고 있다.

11일 정부에 따르면 행정자치부와 미래창조과학부는 공공 웹사이트 및 사용빈도가 높은 민간 기업 웹사이트의 액티브X를 걷어내고 있다. 액티브X로 인해 인터넷 익스플로러를 제외한 크롬·파이어폭스 등의 브라우저에서 웹사이트에 접속할 수 없는 불편함 때문이다.

행자부 관계자는 "공공 웹사이트에서 액티브X 제거가 진행되고 있다"며 "민원발급·열람 등 일부 대국민서비스에는 보안강화를 위해 액티브X 표준기술이 개발될 때까지 사용이 불가피한 측면도 있어 2018년까지 공공사이트에서 액티브X를 차례로 폐지해 100% 폐지할 계획"이라고 밝혔다.

...

단, 불가피하게 HTML5가 지원되지 않는 경우 대체기술인 실행파일(.exe)로 호환성을 확보하고 표준기술이 지원되면 이를 적용한다. HTML5가 국제표준이기 때문에 국내 보안(키보드보안·백신·개인방화벽 등) 및 장치제어(프린터제어 등)에는 호환되지 않고 있다.

"

출처 : 디지털타임스

보안상으론 active x 보다 exe가 덜치명적인지, 더치명적인지는 모르겠지만 저보다 훨씬 유능한 전문가들이 하시는거니깐 잘처리하시겠죠? 대통령 취임하신지 몇일 되지도 않았는데, 공약을 지키기위해서 노력하시는거 같아 보기 좋습니다.

일단 제가 유지보수 하던 사이트는 ActiveX를 거의 걷어내는데 성공했지만, 아직까진 공공기관 사이트들중에서는 ActiveX를 설치하고 공인인증서로 로그인하는 방법을 사용하는곳이 제법 많더군요.

앞으로 웹 표준, 웹호환성 맞는 사이트들이 많아졌으면 좋겠고, 저도 그렇게 만들려고 힘을 써야겠습니다.