NARADESIGN

웹표준, 웹접근성, 유니버설디자인, HTML, CSS, UI, UX, UD


CSS와 웹 접근성. 그리고 장치의 표준화.

본문 건너 뛰기

늘 하는 이야기지만 (X)HTML은 콘텐트의 의미를 마크업하는 구조언어이고 CSS는 화면표시용 언어입니다. 그리고 CSS에 대하여 더욱 정확하게 말하자면 CSS는 화면표시만을 위한 언어는 아닙니다. 간단하게 CSS 미디어 타입 종류를 살펴보는 것만으로도 쉽게 이해가 되실줄로 믿습니다. 아래 목록들을 보시고 CSS 라는것이 웹의 접근성과 무관하지 않다는 것을 이해하시면 됩니다.

CSS Media Type의 종류
  • all (모든 출력 장치)
  • aural (음성 출력)
  • braille (점자 출력)
  • handheld (포켓, 모바일)
  • print (인쇄)
  • projection (투사 장치)
  • screen (스크린, 모니터)
  • tty (전신 타자기, Tele Type Writer)
  • tv (텔레비전, Television)

CSS에 대하여 본격적으로 공부를 해보신 분이라면 저렇게 많은 미디어 타입이 있다는 것을 이미 알고 계실 것입니다. 이러한 미디어 타입은 아래와 같은 문법으로 적용이 가능하게 되는데 특히 인쇄(print)를 위한 미디어 타입은 지금 보고계신 제 블로그에도 사용되어 있습니다. 제 블로그 화면을 웹 브라우저의 인쇄 미리보기 기능을 이용하거나 직접 인쇄 해보시면 모니터(screen)에서 보는 화면구성과는 다르다는 점을 알 수 있습니다. print.css 에는 인쇄물을 위한 코드들이 포함되어 있고 print 라는 미디어 타입을 지정하여 인쇄시에만 이 스타일이 적용되도록 하였습니다. <link href="default.css" rel="stylesheet" type="text/css" media="all" />
<link href="print.css" rel="stylesheet" type="text/css" media="print" />
<style type="text/css">
@import url("default.css") all;
@import url("print.css") print;
</style>
아무런 미디어 타입을 지정하지 않으면 기본적으로 media="all" 을 지정한 것과 같습니다. 그래서 보통은 생략하게 되죠. 하지만 미디어 타입을 잘 활용하게 되면 PC 아닌 다른 장치에서 웹페이지가 제대로 ‘보이거나, 들리거나, 느껴지도록’ 할 수 있습니다. 문제는 이것을 잘 알지만 그동안 거의 신경쓰지 않았다는 점인데 그도 그럴것이 PC 아닌 다른 장치에서 이러한 미디어 타입을 제대로 지원하는 경우(휴대전화, 스크린리더…)는 거의 없다시피 합니다. 그래서 오늘은 표준을 제대로 지원하지 않는 장치들에 대하여 살짝 이야기 해볼까 합니다. 저는 이렇게 표준을 지원하지 않는 장치들에 대하여 불만이 많습니다.

스크린리더와 CSS

저희 한국에서는 ‘센스리더’ 라고 하는 제품이 가장 많이 사용된다고 합니다. 시각장애인들 사이에서는 Internet Explorer와 같은 존재 입니다. 저는 아직 사용해 본적은 없는데 굳이 꼭 사용해 봐야할 필요성까지는 느끼지 않고 있습니다. 왜냐하면 이 제품이 완전히 ‘W3C의 웹 표준 스펙’에 의하여 작동하지는 않으며 그러한 상황까지 고려하여 특정 회사 제품의 장치에 종속적인 웹페이지를 만드는 것이 궁극적으로는 바람직하지 않다고 생각하기 때문입니다.(Internet Explorer 전용 웹페이지를 만드는 것과 똑같은 상황이 됩니다.) 얼마전 대전의 맹인학교 교사분으로부터 메일을 받게 되었는데 CSS를 이용하여 display:none 되어있는 콘텐트를 스크린리더가 모두 읽는 바람에 해당 페이지의 내용을 이해하는데 무척 애를 먹고 있다는 내용이었습니다. 하지만 저는 display:none 되어있는 콘텐트를 스크린리더가 읽지 못한다고 알고 있었구요. 결론부터 말씀드리면 스크린리더는 display:none 되어있는 콘텐트를 무시하는 것이 표준인데 스크린리더가 이 규칙을 지키지 않은 것입니다. 센스리더가 이렇게 웹 표준 스펙을 지원하지 않는 경우를 모두 알지는 못하여 일일이 열거할수는 없지만 제가 알고 있는 것들만 나열하면 다음과 같은 문제들이 있습니다.

  • display:none 되어있는 콘텐트를 읽음. (W3C 스펙에 따르면 읽어서는 안됨.) [첨언] 정확히 말하면 inline 으로 기술된 경우에는 읽지 않지만, 문서 head 에서 기술하거나 외부 파일로 CSS를 분리하는 경우 여전히 읽는 것으로 나타났습니다. 보통의 경우 CSS는 문서의 head에 정의하거나 별도의 파일로 분리하는 것이 일반적이므로 display:none을 여전히 읽는다고 표현하는것이 적절한것 같습니다.
  • 현재 페이지에 대한 앵커<a href="#content">가 제 기능을 하지 않음. (앵커를 클릭하면 해당 id 부분으로 가상의 포커스가 이동하여야 함.) [첨언] 정확히 말하면 테이블 셀(td)를 참조하는 앵커는 인식하지만 콘텐트를 그룹핑하는 목적의 div 태그를 향한 앵커는 인식하지 않습니다.
  • form 콘트롤 요소와 결합된 label 텍스트를 인식하지 못함. (input 영역에 포커스가 위치하게 되면 label 텍스트를 읽어주어야 함.) [첨언] 정확히 말하면 페이지를 순서대로만 읽는 경우에는 인식하고 form 요소만 추출하여 정렬한 다음 포커싱 하면 label을 인식하지 못함.

웹 표준을 준수하고 웹 접근성을 높이기 위하여 나름 애를 쓰고있는 웹 퍼블리셔 분들께서는 이러한 사실을 알게 되는 순간 무척이나 당황스러울 것입니다. 정말 많은 노력을 기울여 접근성이 높은 웹페이지를 만들어 놓았더니 이제는 장치가 표준을 지원하지 않는다니요. 참으로 미칠 노릇입니다. 하지만 제가 이러한 사실을 공개하는 이유는 더이상 접근성을 향상시키기 위한 노력을 그만 두라고 말하기 위함이 아닙니다. 오히려 스크린리더 업계의 파이어폭스가 등장해 주기를 바랍니다. ‘센스리더’를 개선하던지 아니면 누군가 센스리더보다 더 나은 제품을 만들어 준다면 좋겠습니다. 웹페이지는 점점 표준화 되어가는데 이것을 읽어주는 장치가 표준을 지원하지 않는다면 다시 웹페이지를 뜯어 고쳐야 할까요? 아니면 장치를 뜯어 고쳐야 할까요? 답은 분명 합니다. 장치를 뜯어 고쳐야죠. 만약 스크린리더 장치 관련업에 종사하는 분께서 이 글을 보신다면 관계자 분들과 공유해 주십시오. 혼날것은 혼나고 넘어가야 합니다.(저는 CSS 표준 준수율이 최악인 Internet Explorer 제품에 대하여는 더욱 심하게 비판하였습니다.)

모바일장치와 CSS

스크린리더는 CSS의 미디어 타입 가운데 aural 타입과 aural 관련 속성을 지원하여야 하고, 모바일 장치는 handheld 라는 미디어 타입과 관련 속성을 지원하여야 합니다. 웹 접근성에 관심이 많은 분들께서는 스크린리더 뿐만 아니라 모바일 접근성에도 관심이 높아서 모바일 장치를 위한 CSS가 적용된 웹페이지가 있는지 많이들 궁금해 하십니다. 결론부터 말씀드리면 handheld 라는 미디어 타입을 적용한 웹사이트는 가뭄의 콩나듯 존재하지만 handheld 라는 미디어타입을 제대로 지원하는 장치는 제가 아는한 없습니다.(이 대목에서 누군가 그렇지 않다고 발끈해주셨으면 좋겠습니다.) 표준 준수율이 높고 웹 표준을 기업의 철학으로 삼고있는 오페라마저 오페라미니라는 모바일 전용 브라우저에서는 CSS의 표준 속성들을 제대로 지원하지 않고 있는데 이것은 ‘스몰 스크린 렌더링(Small Screen Rendering)’을 위한 다분히 의도적인 것으로 보입니다. 오페라 미니는 handheld용 CSS를 작성해도 레이아웃과는 무관한 일부 속성들(예:color, background)만을 표준으로 지원하며 모든 컨텐트를 작은 화면속에 담아내기 위하여 선형화 시켜버립니다. 이 좋은것을 왜 지원하지 않는지 참으로 궁금합니다. 아마도 기존의 비표준 웹사이트까지 모바일장치에서 렌더링하는데 문제가 없도록 하기 위하여 완벽한 표준을 지원하지 않고 한 걸음 후퇴한것 같습니다. 오페라가 웹의 표준스펙을 몰라서 지원하지 못하는 것은 분명 아닐껍니다. 하지만 만약 모바일 장치들이 handheld 속성을 표준대로 정확하게 지원하게 된다면 진정한 원소스 멀티디바이스(One Sourse Multi Device)가 가능해 집니다. 예를들면 온갖 잡동사니들이 펼쳐진 웹사이트 초기화면의 HTML은 그대로 이용하고 모바일 장치를 위한 handheld용 CSS만을 추가하여 심플한 콘텐트로 변신한 페이지(요즈음 변신이 유행이라죠)를 보여줄 수 있게 되는 겁니다. 제가 너무 순진한 것인가요? 자신이 통제할 수 없는 것에 대한 변화를 꿈꾸는 이런 상황이… 한편 한국에는 인프라웨어라는 업체에서 국내 휴대폰 시장에 공급되는 모바일 브라우저를 생산하고 있는데 그것들이 정확하게 handheld 미디어 타입을 지원하는지 확인할 길이 없었습니다.(뭐 직접 해당 회사에 메일로 문의해도 알 수는 있겠지만 말이죠.) 이에관한 정보가 있다면 피드백 부탁드립니다.(저 대신 누가 메일좀ㅡㅡ;) 어쩌면 지금 여러분이 사용하고 계신 휴대전화기의 웹 브라우저가 이곳 회사 제품일 수도 있습니다.

결론

웹 페이지는 점점 표준화 되어 가고 있습니다. 제가 웹페이지를 제작함에 있어서 표준을 준수하지 않는 장치를 위한 별도의 노력을 기울여야 할까요? 아니면 표준이 아닌 장치를 표준화 해야 할까요? 웹은 점점 모니터 밖으로 뻗어 나아가려고 하는데 담아낼 그릇에 구멍이 났으니 웹이 줄줄 샐 수 밖에요. 장치들이 표준을 지원하지 않으면 웹페이지의 표준화는 결국 밑빠진 독에 물 붓기밖에 안됩니다. 장치의 표준화에도 신경써 주세요. 이것 잘 하면 우리나라가 1등 먹을 수도 있을것 같은데 말이죠.(마땅한 근거는 없습니다. 그랬으면 좋겠다구요.ㅎㅎ)

분류: CSS,웹 접근성,웹 표준 | 2007년 7월 20일, 0:07 | 정찬명 | 댓글: 21개 |
트랙백URI - http://naradesign.net/wp/2007/07/20/125/trackback/

21개의 댓글이 있습니다.

  1. 1UP 댓글:

    handheld 타입을 사용하는 사이트를 본 적이 없어요.;;
    좀 유명한곳에 뒤저보면 나오려나요..

    그리고 설마 했었는데 스크린 리더가 display:none 을 읽어버리는군요 -_-
    안보여 주겠다는걸 왜 들추는건지.. ㅎㅎ

  2. 신현석 댓글:

    표준 자체에 대한 고민도 필요합니다. 구현되지 않은 표준은 표준이 아닙니다. 지금 웹표준에 대한 관심이 높은 것도 파이어폭스가 있었고 브라우저 벤더들이 지원을 하고 있기 때문입니다. 만약 IE6가 지금 수준 정도도 지원하고 있지 않았으면 웹표준이라는 말은 무색했을 것입니다. 그래서 웹표준 프로젝트에서도 브라우저 벤더를 위한 TF가 존재하는 것이고요.

    핸드핼드 미디어 타입의 경우, 단순히 브라우저 벤더에서 왜 지원하지 않을까를 논하기 보다는 왜 구현한 곳이 하나도 없을까를 생각해 보는 것이 더 좋을 것 같습니다. 현재 가장 유명한 모바일용 브라우저인 오페라 미니와 사파리 둘 다 핸드핼드를 지원하고 있지 않습니다. 인터페이스가 진보되면서 과거의 표준에서 충분히 고려하지 못한 영역이 생기게된 것입니다.

    표준이 절대적인 것은 아닙니다. 오히려 이런 단계에서는 표준을 고민하고 어떻게 보다 더 나은 표준을 만들 수 있을 것인가를 생각해 보는 것도 좋을 것 같습니다.

  3. Na! 댓글:

    원소스 멀티디바이스..
    개인적으로도 가장 유력한 파일형식(?)은 (X)HTML이라 생각합니다.
    XML도 있지만.. 이녀석은.. 강력하기는 한데..보편성라는 측면에서 밀리는듯 합니다.

    (예을 들면 제 전직업이었던 토목설계쪽에서도 도면을 특정 XML형식으로 아웃해주는게 있는데…
    그게 무려 광범위한 지형테이타를 가진 것이라도 말입니다. 다만..사람이 읽어서 해석은 거의 불가능입니다.. 기계들의 호환을 위한 기능이었다고 생각됩니다. 그러나 HTML은 사람이 읽어서도 해석이 가능하다는데 있어 멀티의 폭이 더 광범위하다고 생각됩니다.)

    핸드폰.. PMP등으로 원활한 웹 접속과 서핑 참으로 편리한 세상이 될듯한데..말이죠..
    (그러고보니.. 휴대용 게임기 닌텐도DS에도 오페라브라우져 가 탑재되어 있죠..
    접속율이 얼마나 될지는 모르지만..)

    멀티디바이스을 막는 어둠의 집단이 있지 않나 생각합니다.
    마치 중세유럽어디선가.. 지배체재 강화를 위해 일반 평민에게 교육은 물론 글자도 가르쳐 주지 않았다는 이야기처럼.. 정치적 지배가 아니더라도 경재적 이유에서가 아닐지.. (음모론에..)

    그래도 표준을 준수한 웹을 만드는게 웹제작에 관여 하는 사람으로서 올바른 태도라 생각합니다.
    설마 새로 나오는 어떤기기가 기존 표준을 완전 갈아업고 대채할 포맷을 만들어 낼 가능성은 극히 적으니까.. 현존 표준에.. 맞추어 나오겠죠.. (이런걸 상위 호환성을 고려한 웹 구축이라 했던가요..?)

    이상하게 여기 덧글을 길게 쓰는 – [Na!] (블로그 만들어 트렉백을 걸어야 할까.. –a)

    [개인적 궁금한점.. 입니다만.. 답변이 가능하시면..부탁드립니다. ]

    얼마전 [Naver] 와 [KT]가 IP TV에 관한 건으로 제휴를 했다고 보도 됐는데.. 내용인즉 [Nave]r의 서비스를 [KT]의 IP TV의 망을 통해 서비스한다는 것으로 기억합니다.. 그러다면.. 디스플레이는 TV일꺼라고 생각되는데.. 거기에 뿌려질 [Naver]의 정보형식은 어떤 형태일까요.. HTML /NTSC Video.. 아니면.. 다른 무언가.. 그리고.. 인터렉션은 어떻게 이루어질까요..?

    (개인적으로는 웹이 디스플레이 되는 TV의 리모컨의 진화는 닌텐도 Wii의 컨트롤러 같은 형식이 되지 않을까 생각하고 있습니다만.. 설마.. [KT] IP TV 셋톱박스는 닌텐도 wii!!)

    위의 질문 내용이 회사 기밀이시라면.. 어쩔수 없지만. 괜찮으시다면.. 지식의 공유를 부탁드립니다.

  4. 이정주 댓글:

    아 새로운거 많이 깨달았습니다. 그리고 선배님의 답답함이, 접근에 대한 뜨거운 욕망이 느껴지내요. 선배님 덕에 모든사람이 웹의 접근에 있어 불편함이 없어졌으면 좋겠습니다.

    아 참고로 대전에 맹인 학교 저희 집 근처예요. 자주 학생들을 태운 차를 보게 됩니다. 얼마나 답답할까요? display:none까지 귀기울여야 하니…그리고 요새 용돈벌이로 하는일이 한국문화재 대국민 서비스 분석설계 하는데 표준은 씨도 않먹히내요(겨룰도 없지만).T_T 접근이 불편한분들은 어떻게 한국 문화재를 볼지…걱정이 앞섭니다.

  5. 타브리스 댓글:

    글 잘 읽어 보았습니다. 한가지 의문점이 생겨 이렇게 글 남깁니다.

    저 또한 웹접근성에 대하여 관심을 가지고 있고 실제로 이번에 동기 홈페이지를 만들면서 웹표준을 지키며 만들어 보았습니다.

    그런데, 제가 홈페이지를 만들 때 본문바로가기나, 메뉴바로가기 등 앵커를 이용해서 페이지 상단에 코딩해주고 스타일시트로 display: none 처리해 주었거든요.

    그렇게 해두면 우리는 못 보지만 스크린리더 프로그램을 사용하는 시각장애인이 사용할 수 있다고 어디선가 봤습니다.

    이 포스트에 의하여 웹표준을 준수하는 스크린리더 프로그램에서는 그 앵커 링크를 사용할 수 없다는 것인데. 그렇다면 웹표준을 준수하며 같은 역할을 하게 하려면 어떻게 해야 하나요?

    살짝쿵, 머리에 혼란이 오네요.. ^^;

  6. Antiterror 댓글:

    휴 정말 많은 것을 배웠는데, 글을 다 읽고 다니 씁쓸해지네요..
    저는 고등학생으로 웹 표준, 웹 접근성에 많은 관심을 두고 있는 학생인데.. 제 친구들한테도 웹 표준을 지켜가며 홈페이지를 만들어라! 라고 강조하고 있는데, 괞히 그 친구들한테 미안해지네요..

    1등은 아니여도, 대한민국 웹 에도 웹 표준이 널리 알려졌으면 하는 바램입니다 ^^

  7. 정찬명 댓글:

    휴~ 댓글을 많이들 주셨군요. 댓글 다는데 한참 걸리겠는데요.

    1UP님께,
    handheld 타입이 사용된 좀 유명한 오페라 웹사이트 안내해 드립니다.(물론 알고 계시겠지만 다른분들을 위해서^^)
    http://www.opera.com/
    http://www.opera.com/css/handheld.css
    특히 오페라 미니에서 지원하는 CSS 속성에 어떤 것들이 있는지 알고 싶으시다면 handheld.css 를 살펴보시면 도움이 되실것 같습니다.

    현석님께,
    현석님 말씀 듣고 ‘닭과 달걀’에 관한 논쟁이 떠올랐습니다. 모바일 웹 브라우저가 handheld를 지원하지 않는것은 이것을 지원하는 웹페이지가(수요) 없기 때문인지, 아니면 거꾸로 모바일 웹 브라우저가 handheld를 지원(공급)하지 않기 때문에 handheld 를 지원하는 웹페이지가 없는것인지… 한마디로 애매 하다는거죠.ㅡㅡ; 비록 W3C가 최신기술을 예측하지 못하고 진부한 표준을 권장하고 있는 부분이 있다손 치더라도 표준을 준수하는 것은 표준을 준수하지 않는 것보다 얻을 수 있는 득이 훨씬 더 크다고 생각합니다.

    Na!님께,
    ‘멀티디바이스를 막는 어둠의 집단’은 물론 농담이시겠죠^^ 좀 쌩뚱맞지만 변증법 적유물론의 이론을 빌면 ‘웹을 안정된 구조로 유지하려는 [정]’과 ‘웹을 확장하고 발전시키려는 [반]’이 존재할 것인데 그 중 웹을 확장하고 발전시키려는 [반]의 세력을 ‘어둠의 집단(실제로 어둡지는 않지만)’에 비유할 수 있을 것 같습니다. 정과 반은 갈등을 통해서 [합]이 된다죠. 새가 좌우의 날개를 모두 이용해서 날 수 있는 것처럼. 비록 저희들이 왼쪽 날개짓만 담당하고 있을 지언정 오른쪽 날개와의 갈등과 조율은 필요하다고 생각합니다. 마지막에 해주신 질문은 회사 기밀이 아니라고 하더라도 제가 아는게 없어서 말씀드릴 수가 없습니다. 죄송합니다ㅡㅡ; (저는 저희 회사 소식을 주로 회사 바깥의 뉴스를 통해서 접하고 있습니다.ㅜㅜ; 아마 저같은 사람들 많을껄요.ㅎㅎ)

    정주님께,
    ‘접근에 대한 뜨거운 욕망’ 이 표현 무척 마음에 드는데요ㅋㅋ. 맹인학교 같은 곳에 일반 학생들을 위한 ‘장애인 체험교육’과 같은 프로그램이 있는지 알아보세요. 만약 그런 프로그램이 있다면 후배들 데리고 한번쯤 다녀와 볼만한 좋은 ‘인생 경험+웹 접근성 교육’이 될꺼라고 생각합니다. 해외에 나가서 새로운 문물을 익히고 다녀오는 것보다는 돈도 적게 들고 더욱 값진 경험이 될꺼라 생각해요.(저도 아직 기회가 없어서 가보지 못했답니다. 하지만 언젠가는 꼭~)

    타브리스님께,
    방법이 있습니다. display:none 이 아니더라도 콘텐트를 시각적으로 숨기는 방법은 다양합니다. 그 가운데 제가 추천드리는 방법은 다음과 같습니다. 아래 코드는 스크린리더의 CSS 표준 지원 여부에 관계없이 접근성 높은 스킵 네비게이션 메뉴를 제작하는 방법입니다.

    a#skipToContent { display:block; height:0; overflow:hidden;}
    a#skipToContent:hover,
    a#skipToContent:focus,
    a#skipToContent:active { height:auto}

    너비 또는 높이를 0px 로 만들고 넘치는 부분을 보이지 않게 overflow:hidden 시키는 방법이죠. 이 방법은 키보드에 의하여 앵커에 포커싱이 되면 해당 영역이 보이게 됩니다. 저는 포커싱 되었을 때 이렇게 눈에 보이는 것이 좋다고 생각하는데 이 기능은 시각장애인에게만 유용한 것이 아니기 때문입니다. 키보드를 잘 쓰는 사람도 이 기능의 도움을 받을 수 있습니다. 예제를 테스트 해보시려면 예제 페이지를 방문해 보세요. http://naradesign.net/open_content/reference/navigation.html

    Antiterror님께,
    저는 고등학생때 노는것 밖에 몰랐는데 이런 고민까지 하고있는 Antiterror님 같은 후배들이 있다는 것을 생각하니 정말 대견하고 자랑스럽습니다. 친구에게 미안해 하지 마세요. 그 친구는 나중에 Antiterror님을 고맙게 생각할껍니다. 처음 제게 레이아웃을 위한 테이블을 쓰지 말라고 다그쳤던 분들을 지금은 무척 고맙게 생각하고 있습니다. 그리고 ‘웹 표준 너머의 인류평등’ 가치는 지금 제 일에 있어서 가장 중요한 철학과 사명이 되었습니다.

  8. 타브리스 댓글:

    예제 페이지 감사합니다. 웹표준, 웹접근성에 대한 관심이 높아져 가면서 엉터리 정보들도 늘어가고 있는 것 같네요. ^^;;

    이곳에는 저에게 도움이 되는 자료가 정말 많은 것 같습니다. 앞으로도 틈틈히 들리겠습니다.

  9. 가우리 댓글:

    세상 참 좁네요…

    Antiterror님 저의 학교 후배입니다. ㅠㅠ

  10. 정찬명 댓글:

    타브리스님께,
    감사해요!

    가우리님께,
    어쩐지… 선린인터넷고등학교 학생들은 생각이 정말 남다르군요. 이런건 칭찬해 줘야할것 같아요!

  11. freeism 댓글:

    (댓글 타고 왔습니다)
    좋은 글 감사합니다.
    XHTML을 공부하는 학생[!!!]으로서(직딩입니다^^) 공감이 많이 가는 글이네요.
    display:none 은 안 읽어서 오히려 문제가 되는 부분(꽁수로 디자인 하는 경우에)이 있다는 말은 들었어도 저런 경우는 처음이네요;;;
    공감대의 글로 제 블로그의 글을 하나 소개해 드립니다.

    http://ismvisualstudio.net/blog/freeism/47

    이 곳에 보시면 글 아랫쪽에 ‘박찬준님’의 글을 인용한 부분이 있습니다.
    웹 표준은 디자이너나 개발자만 지킨다고 되는 것이 아니라는 생각이 공감되는 것 같습니다. ^^

    자주 들르겠습니다~ 좋은 하루 되세요~

  12. 정찬명 댓글:

    freeism님의 좋은 글도 잘 보았습니다. 하지만 참조하신 박찬준님의 글이 문제의 본질을 해결하는 방식이 아닌점은 아쉽습니다. 즉, 리눅스에는 IE가 설치되지 않기 때문에 IE에 최적화된 웹페이지가 결코 면죄부를 받게 되는것은 아니라는 의견입니다. 윈도우즈 환경만 생각한다면 Tab Browsing 등을 이용하여 렌더링 엔진을 전환하는 것이 가능하지만 그럴 수 없는 기타 OS 환경에서는 여전히 마땅한 대안이 없는 미봉책일 뿐이며 웹 브라우저 회사는 표준 기반의 렌더링을 지원하고 웹페이지 제작자는 표준 기반의 코드를 생산해 내는것이 현존하는 가장 적절한 대안이라고 생각합니다.

  13. 웹 접근성.. 그럼 플래시는 어떨지…..

    나라디자인 : http://naradesign.net/wp/웹표준에 대해 조금 공부 잠깐 하면서 종종 들리는 정찬명님의 블로그입니다.CSS에 대해 아리까리한 포스팅을 올리면 갑자기 어디선가 나타나서 시원한 해법…

  14. 백남중 댓글:

    본문의 내용 중에서 스크린 리더와 css 부분에서 현재 스크린 리더(센스 리더)와 다른 부분이 있어서 적습니다.

    ● display:none 되어있는 콘텐트를 읽음. (W3C 스펙에 따르면 읽어서는 안됨.)
    – 예전에는 드림보이스, 센스리더 모두 display:none을 읽었으나, 금년 7월에 업그레이드 된 센스리더 1.4에서는 읽지 않게 하였습니다.
    또한 센스 리더는 display:none이라고 정의했어도, 사용자가 강제적으로 읽게 할 수도 있게 하였습니다.

    ● 현재 페이지에 대한 앵커 [a href=”#content”] 가 제 기능을 하지 않음. (앵커를 클릭하면 해당 id 부분으로 가상의 포커스가 이동하여야 함.)
    – 센스리더, 드림보이스 모두
    현재 페이지에 대한 앵커를
    [a href=”#content”] ~ [a name=”content”]
    로 정의한 것은 제대로 작동합니다.
    그러나 정찬명님의 블로그 처음에도 나타나 있는
    [a href=”#content”]본문[/a] ~ [div id=”content”]
    로 이동하게 한 것은 제대로 이동하지 않습니다.
    이것은 스크린 리더가 [div] 를 제대로 파악하지 못했기 때문이라고 생각합니다.

    ● form 콘트롤 요소와 결합된 label 텍스트를 전혀 인식하지 못함. (input 영역에 포커스가 위치하게 되면 label 텍스트를 읽어주어야 함.)
    – form 콘트롤 요소와 결합된 label 텍스트는 다음과 같이 음성 출력합니다. label을 전혀 인식 못한다는 것은 오해이신듯 합니다.
    (편집창이라고 쓰인 부분은 센스리더, 드림보이스가 편집창에 위치한 경우 소리내는 것입니다.)

    원본: [label]이름:[/label] [input type=”text”]
    센스 리더 1.4: 이름:, 편집창
    드림보이스6.0: 이름:, 편집창

    원본: [label]이름:[/label] [input type=”text”]
    센스 리더 1.4: 이름:, 편집창
    드림보이스6.0: 이름:, 편집창

    원본: [input type=”text” label=”name”]
    센스 리더 1.4: 편집창
    드림보이스6.0: 편집창

    원본: [input type=”text” title=”이름”]
    센스 리더 1.4: 이름, 편집창
    드림보이스6.0: 편집창

    원본: [label]이름[input type=”text”][/label]
    센스 리더 1.4: 이름, 편집창
    드림보이스6.0: 이름, 편집창

    원본: [label for=”name”]이름[/label][input type=”text” id=”name”]
    센스 리더 1.4: 이름, 편집창
    드림보이스6.0: 이름, 편집창

    백남중

  15. 정찬명 댓글:

    백남중 부장님께,

    본문에 HTML 마크업을 사용하셔서 작성하신 글이 다소 깨져있었습니다. 제가 꺽쇠를 모두 [괄호]로 변경하였습니다. 어떤 단어나 문장은 태그 때문에 자동으로 삭제되어 있을 수도 있습니다. 양해 부탁드립니다. HTML 태그를 사용할 때 열고 닫는 꺽쇠는 반드시 괄호로 변경해 주셔야 내용이 제대로 작성됩니다.

    display:none 관련하여,
    display:none 콘텐트를 읽지 않는 경우는 CSS 를 inline 형식으로 선언했을 때 뿐이었고, 문서의 head 에 첨부하거나 외부 파일로 CSS 를 빼두는 경우 여전히 display:none 콘텐트를 읽습니다. 보통 CSS를 선언할 때 문서의 head 에 정의하거나 외부로 빼는 경우가 대부분이므로 보통의 경우 센스리더는 display:none 콘텐트를 읽는다고 표현하는 것이 맞을 것 같습니다. 이와 관련하여 신현석님께서 정리해 둔 문서가 있으므로 다른분들께서는 참조해 보시기 바랍니다. http://hyeonseok.com/temp/screenreaderdisplaynone.html

    a 태그(앵커) 관련하여,
    제 블로그 상단에 위치한 a 태그가 센스리더에서 기능하지 않는 원인은 a 태그 자체에 있는 것이 아니라 a 태그가 참조하고 있는 콘텐트의 마크업이 무엇인지에 따라 기능하지 않는 것으로 보입니다. 레이아웃을 위하여 table 구조가 사용된 경우 [td id=”content”] 라는 항목을 참조할 때에는 제대로 기능하지만 [div id=”content”] 라고 마크업된 항목을 참조할 때에는 기능하지 않는다고 말씀하셨습니다. 이것은 센스리더가 현재 HTML 에 대한 이해 없이 개발되어 있다는 것을 말합니다. 앵커는 div 태그를 참조하고 있는 경우에도 기능하여야 합니다. 센스리더 제품이 앵커를 인식하도록 하기 위하여 레이아웃을 위한 table 구조로 마크업 하는 사례는 없었으면 좋겠습니다. 센스리더가 이 부분을 곧 수정해 주시겠죠.

    label 관련하여,
    조금전에 센스리더 교육 경험이 있는 윤좌진님께 물어보았는데 이 부분은 백남중 부장님께서 지적하신것이 맞습니다. 페이지를 순차적으로 탐색하면 label 태그를 인식한다고 알려주더군요. 하지만 보통 시각장애인의 경우 그러한 방법보다 form 컨트롤 요소만 별도로 추출하여 정렬시킨 다음 읽는 방법으로 탐색한다고 하였는데, 이러한 경우에는 input 과 짝지어진 label 을 인식하지 못한다고 하였습니다. 따라서 모든 경우에 label 을 인식하지 못하는 것이 아니므로 제 언급이 정확히 맞는 것은 아니었습니다.

    제 원문 글에 오해 소지가 없도록 세부내용을 정정하도록 하겠습니다.
    잘못된 원문을 바로잡을 수 있도록 도와주셔서 감사드립니다. (__)

  16. 정찬명 댓글:

    백남중 부장님이 새로 적어주신 댓글을 원문에 덮어쓰기 하고 나중에 등록해 주신 글은 삭제 하였습니다. 양해 부탁드립니다. 그리고 제 원문의 해당 부분을 수정하였습니다. 감사합니다 ^^

  17. 백남중 댓글:

    고맙습니다.

  18. 김군우 댓글:

    안녕하세요. Standard Magazine에서 겨미겨미라는 닉을 쓰는 김군우라고 합니다.
    댓글들을 보다 보니 label과 form control의 관계가 Standard Magazine에서 얘기되던 그것과는 좀 다른 것 같군요.
    http://forum.standardmag.org/viewtopic.php?id=1519

    댓글대로라면 [label]뭐시기[input type=”text” value=”blah” /][/label] 류의 코드 사용이 접근성에 저해요소는 되지 않지 않을까요?

    항상 잘 보고 있습니다. 오늘도 좋은 하루 되시길… ^.^

  19. 정찬명 댓글:

    김군우님께,
    label 태그에 for 속성을 사용하지 않아도 스크린리더가 읽어주기 때문에 문제가 없지 않을까 라는 견해 이신데요. 위에서 말씀드렸지만 시각장애인이 웹 페이지를 순차적으로만 읽는다면 말씀하신 대로 코딩해도 문제는 거의 없을 껍니다. 왜냐하면 for 속성을 사용하지 않았지만 label 문자가 input 요소와 인접하여 있기 때문에 순차적으로 읽는 경우라면 문제가 없죠. 하지만 form 콘트롤 요소들만 추려내어 읽는다고 가정 했을 때가 문제입니다. 해당 input 에 대한 label 이 명시적으로 지정된 상태가 아니기 때문에 대부분의 스크린리더 장치가 label을 인식하지 못한다는 겁니다. 그래서 W3C 에서는 for 속성을 사용할 것을 권장하고 있는겁니다. 백남중님께서 테스트 하신 데이터들은 웹페이지를 그냥 순차적으로 읽었을 때의 현상을 기록하신 것으로 압니다.

  20. 한혜진 댓글:

    제 PC에서 테스트 했을 때도 그렇고,
    http://hyeonseok.com/temp/screenreaderdisplaynone.html 이 URL에 들어가서 테스트 했을 때도 그렇고

    display:none 을 인라인으로 주었을 때나 외부파일로 선언했을 때나, 그 외 여러경우에도 모두 읽어주었습니다.

    DTD도 바꿔보고 캐릭터 셋도 바꿔보면서 몇번씩 테스트 해보았으나 같은 결과네요.

    테스트 스펙은 아래와 같습니다.

    센스리더 버전 : v2.1.0.3
    OS : XP pro
    DTD : quirks, transitional, loose, xhtml
    캐릭터셋 : euc-kr, utf-8

    어떤게 정확한지 모르겠지만, 이제 업그레이드 된 버전이 읽어주지 않는다니 다행입니다.
    하루 빨리 세스리더 파워 버전이 자동 업그레이드가 되었으면 좋겠네요~

  21. 정찬명 댓글:

    센스리더 버전 차이 때문에 발생하는 문제가 맞는것 같아요. ^^

댓글 쓰기

전송된 글이 나타나지 않는다면 필터링 된 것입니다. dece24앳gmail.com 으로 메일 주세요.
(X)HTML 코드 사용이 가능하지만 소스 코드 출력을 원하시면 <꺽쇠>는 [괄호]로 변환하여 작성해 주세요.

필수 아님

필수 아님