Feed on
Posts
Comments

웹 접근성은 정의상 장애를 가진 사람들이 동등하게 웹 서비스를 이용할 수 있도록 하기위한 목적을 가지고 있습니다. 그러나 그로 인해 일반사용자들이 불편을 감수하면서 까지 접근성을 확보해야 하는것은 아닙니다. 한국에는 한국형 웹 콘텐츠 접근성 지침이라는 웹사이트에서 웹 콘텐츠를 제공할 경우 지켜야하는 웹 접근성 지침 표준문서가 있습니다.

지난 9월 민간개발자를 대상으로 하는 웹 접근성 교육에 참여 했습니다. 그 중에 한국형 웹 콘텐츠 접근성 지침 2.0 에 대해 알아보는 시간이 맡았는데요 자료와 핵심 내용만 간략하게 정리해서 블로그에 적으려 합니다.

한국형 웹 콘텐츠 접근성 지침(KWCAG)은 W3C의 웹 콘텐츠 접근성 지침(WCAG)를 한국 실정에 맞게 알아보기 쉽게 구성한 표준문서입니다. 현재는 1.0이 국가표준이고 2011년 2.0으로 국가표준이 개정될 예정입니다. 구성은 크게 4가지의 원칙과 13가지의 세부 지침으로 구성되어 있고 각 세부 지침별로 사례별 기술지침이 부가적으로 포함되어 있습니다. 자료 내용과 함께 내용을 확인하시면 좀 더 쉽게 이해할 수 있을거라 생각합니다.
의미의 모호함을 없애기 위해 “적절한” 이라는 단어를 가급적 사용하지 않았습니다.

첫째, 인식의 용이성(Perceivable)
기본 원칙은 모든 콘텐츠는 사용자가 인식할 수 있어야 하는것이며 세 가지 세부지침으로 나누어진다.

  • 텍스트가 아닌 콘텐츠에는 대체 텍스트를 제공해야 한다.
    텍스트가 아닌 콘텐츠는 그 의미나 용도를 이해할 수 있도록 대체텍스트를 제공해야 한다. 충분한 대체텍스트를 제공하는 것이지 너무 불필요한 모든 내용을 대체텍스트로 제공할 필요는 없다는 것이 요다. 제공된 대체텍스트는 일반적인 접근을 하지 못하는 사용자 뿐만 아니라 예외적인 상황에서는 일반인들에게도 유용할 수 있다.
    만약 너무 복잡하거나 긴 콘텐츠를 대체텍스트로 제공해야 한다면 별도의 부가설명페이지가 마련되어 있는 링크를 직접 추가해두거나 longdesc 속성을 이용하여 대체텍스트를 제공할 수도 있다.
    하지만 국내 스크린리더 사용자들중 longdesc의 옵션을 사용할 줄 아는 사용자가 많지 않아 longdesc 보다는 alt 속성으로 되도록이면 제공하는것이 좋다는 의견도 최근에 있었다.
  • 동영상, 음성 멀티미디어 콘텐츠를 이해할 수 있도록 대체 수단을 제공해야 한다.
    동영상은 소리를 들을 수 없는 사용자나 영상을 볼 수 없는 사용자를 위한 대체 수단이 필요하다. 가장 쉬운 방법은 자막이나 원고를 첨부하는 것이고 수화는 소리를 들을 수 없는 사용자를 위해 추가로 제공하는 것이다. 자막은 수정이 불가능한 닫힌자막과 사용자가 수정이 가능한 열린자막으로 나눌 수 있으며 되도록이면 열린자막을 제공하는것이 좋다. 열린자막은 사용자의 환경에 맞게 크기, 색상, 속도 등을 조절할 수가 있으며 언어의 변환이나 검색에도 용이하기 때문이다.
  • 콘텐츠는 명확하게 전달되어야 한다.
    콘텐츠는 색상에 관계없이 인식이 가능하도록 제작되어야 하며 방향이나 모양 크기나 위치 색상등을 지시할 경우에는 명확한 설명이 있어야 한다. 저시력자를 위해 텍스트의 색상은 12px을 기본 크기로 가정할 경우 약 4.5대1의 비율 이상으로 설정해야 한다. 음성을 이용하여 접근하는 사용자를 위해 자동으로 배경음이 실행되도록 해서는 안되며 반드시 필요한 경우 3초 이상을 넘기지 말거나 사용자가 선택이 가능한 기능이 마련되어야 한다.
    전경색 배경색 색 대비 알아보는 차트(#ffffff 기준)

둘째, 운용의 용이성(Operable)
기본 원칙은 사용자 인터페이스 구성요소는 직접 조작이 가능하도록 구성되어야 하고 네비게이션(이동)할 수 있어야 하는것이며 네 가지 세부지침으로 나누어진다.

  • 콘텐츠는 키보드로 접근할 수 있어야 한다.
    마우스를 사용하지 못하는 환경이나 사용자들을 위해 키보드만으로 사용할 수 있도록 제공해야 하며 마우스에서만 동작이 가능한 스크립트 이벤트(onmouseover, onmouseout)는 키보드 이벤트도 함께 제공하는것이 좋다. 키보드가 접근할 경우 기본적으로 표시되는 초점(아웃라인)이 없어지지 않도록 스타일 사용에도 주의해야 하며 접근순서가 구성요소의 논리적인 순서와 다른 순서로 이동되어서는 안된다.
  • 콘텐츠를 읽고 사용하는데 충분한 시간을 제공해야 한다.
    콘텐츠를 읽는데 시간제한이 있다면 불편할 것이다. 그러나 어쩔 수 없는 경우 그 시간제한을 사용자가 조절할 수 있는 기능만이라도 제공된다면 불편이 줄어들 것이다. 이런 경우는 콘텐츠가 움직이거나 이동한다던지 페이지가 자동으로 이동되는 경우나 서식 작성시 보안이나 로그인 세션 문제 등의 이유로 작성 제한시간이 주어지는 경우 일 것이다.
  • 광과민성 발작을 일으킬 수 있는 콘텐츠를 제공하지 않아야 한다.
    광과민성 발작을 일으키는 사용자가 느끼는 광과민성 콘텐츠는 초당 3회에서 50회의 깜빡임이다. 주로 gif 애니메이션 이나 플래시를 이용한 콘텐츠에서 문제가 발생하며 자주 사용되는곳은 없지만 <blink> 나 <marquee> 등을 사용할 경우에도 문제가 발생할 수 있다.
  • 콘텐츠는 쉽게 내비게이션 할 수 있어야 한다.
    쉽게 내비게이션할 수 있어야 한다는 것은 쉽게 이동할 수 있어야 한다는 말이다. 이 말은 두가지의 의미로 해석할 수 있으며 실제로 콘텐츠별 영역으로 쉽게 이동이 가능하도록 해야 한다는 것과 그렇게 이동하기 위해서는 링크의 명확한 목적설명이나 독립적인 페이지 타이틀을 제공한다던지 콘텐츠 블록에 콘텐츠를 설명하는 제목을 제공해서 어떠한 내용이나 용도, 목적을 가지는 콘텐츠인지를 인식할 수 있도록 제공해야 한다는 것이다.

셋째, 이해의 용이성(Understandable)
기본 원칙은 콘텐츠를 쉽게 이해할 수 있어야 하는것이며 네 가지 세부지침으로 나누어진다.

  • 콘텐츠는 읽고 이해하기 쉬워야 한다.
    문서를 구성할 때 문서에서 사용되는 주 언어가 무엇인지를 선언해야 한다. 선언한 언어 코드는 음성인식 보조기기와 번역프로그램 그리고 검색엔진에 정확한 단어와 문장의 뜻으로 제공되어 도움을 줄 수 있다.
    공식언어코드(ISO 630) 목록
  • 콘텐츠의 기능과 실행결과는 예측 가능해야 한다.
    사용자가 의도하지 않은 동작이 발생하지 않아야 한다. 예를 들어 셀렉트박스 리스트를 선택했을 뿐인데 script 이벤트나 페이지 이동이 일어나서는 안되고 링크를 클릭했을 때 사용자가 예측하지 못하게 새창으로 이동되어서는 안된다.
  • 콘텐츠는 논리적으로 구성해야 한다.
    콘텐츠를 구성할 때는 논리적으로 콘텐츠가 순서에 맞게 구성이 되어야 하며 스타일이 더해진 상태에서도 마찬가지여야 한다. 표(<table>)를 구성하더라도 이해하기 쉽게 구성이 되어야 하며 되도록 데이터 표가 아닌 콘텐츠를 <table>을 이용해서 구성하지는 않아야 한다.
  • 입력 오류를 방지하거나 정정할 수 있어야 한다.
    서식을 입력하는 컨트롤에는 어떤 내용을 입력하는지에 대한 레이블이 제공되어야 한다. 만약 제공이 어렵다면 title 속성으로라도 대체해야 하고 컨트롤별 그룹이 필요한 경우(예를 들어 비슷한 내용을 입력해야 하는 컨트롤들이 있거나 하나의 질의에 대한 답변을 선택하는 라디오버튼이나 체크박스 들의 그룹)<fieldset>을 활용하여 그룹시키고 <legend>로 용도나 목적을 설명하는 것이 좋다.

넷째, 견고성(Robust)
기본 원칙은 미래의 기술로도 웹 콘텐츠를 접근하는데 무리가 없도록 견고하게 만들어야 하는것이며 두 가지 세부지침으로 나누어진다.

  • 웹 콘텐츠는 마크업 언어의 문법을 준수해야 한다.
    다양한 기술이 웹 콘텐츠에 문제 없이 접근할 수 있는 가장 기본적인 조건은 올바른 문법으로 웹 콘텐츠를 제작하는 것이다. 당연한 말이지만 문법은 문서선언(DOCTYPE)에 맞게 작성되어야 한다.
  • 웹 애플리케이션은 접근성이 있어야 한다.
    콘텐츠에 포함된 웹 애플리케이션은 자체적인 접근성이 있어야 하는데 만약 그러지 못할 경우를 대비해서 대체 콘텐츠를 제공해야 한다. 다만 브라우저마다 애플리케이션의 대체기법을 인식하는데 차이가 있기 때문에 주의를 해야 한다.

.
.

여기 까지가 자료의 핵심 내용입니다. 아직까지는 웹 접근성 품질마크 인증을 위해서 1.0 기준을 따라야 하지만 곧 2.0으로 바뀔 것이기 때문에 미리 알아 두는 것이 좋겠다는 생각입니다. 하지만 주요 내용이 크게 달라지지 않기 때문에 1.0을 잘 준수하고 있었다면 큰 어려움이 없다고 생각됩니다.
한국형 웹 콘텐츠 접근성 지침 2.0 에 대한 TTA표준 문서는 되도록 읽어 보는것이 좋습니다. 왜냐하면 이 자료는 한국형 웹 콘텐츠 접근성 지침 2.0을 단지 알기 쉽도록 제작했기 때문에 깊이 이해하기는 힘들 수 있습니다.

관련 자료는 아래 slideshare 프리뷰문서로 확인이 가능하고 pdf 파일로 다운받아서 참고할 수 도 있습니다. 만약 다른 곳에서 공유할 경우 조그맣게 출처 밝혀주면 고맙겠습니다. :)

한국형웹콘텐츠접근성지침2.0알아보기.pdf
관련 자료

지난주 토요일(5월 29일), 한국정보화진흥원에서는 CDK가 주최하는 제 4회 웹 표준의 날 이 있었다.
제 4회 웹 표준의 날

2006년에 처음 생겨났던 이 모임은 1회, 2회, 3회를 거쳐 올해 4회를 진행하고 있는 CDK 공식 행사이다.

웹표준의날 후기는 1회부터 작성했던지라 후기를 적기 전에는 항상 지난 모임 후기 글(1회, 2회, 3회)을 한번 씩 읽어보곤 하는데 매번 후기를 볼 때마다 마치 그 글이 어제 일 처럼 떠오르면서 “벌서 이렇게 시간이 흘렀구나..” “몇몇 보이지 않는 분들의 소식도 궁금하네..” 라는 생각이 들곤 한다.

이번 네번째 웹 표준의 날은 “본격! 웹 표준” 이라는 주제로 웹 표준과 UI개발이 이제는 대중적인 단어로 사용될 만큼 웹 서비스 사이에서 자연스럽게 나오는 이야기가 된 것에 대해, 그렇다면 이후에 준비해야 할 것들이 무엇인지에 대해서 알아보고자 했던 자리라고 생각한다.

발표에는 현석님이 다양한 브라우저 이야기와 생각들을, 찬명님이 CSS3에 대해 예제와 생각을 전달해주셨고, 조훈님이 휴대기기와 디바이스 독립적인 환경에서 웹의 무한한 가능성에 대해, 백남중님이 RIA 환경에서의 접근성과 HTML5에서 생각해볼 접근성에 대해서, 그리고 내 발표현준호님이 웹 콘텐츠 접근성 지침 2.0에 대한 소개를 재미있게 해주셨다.

이후 한동안 활동이 없었던 KWAG에 대한 부활과 활동 예고에 대해 장성민님이 해주셨는데 개인적으로도 많이 기대가 되는 부분이여서 다음 KWAG모임이 기대가 되었었다.
모임의 모든 발표가 끝난 후 웹표준경진대회가 있었는데 운영진들과 문제를 출제 하면서 많은 고민을 했었지만 이날 경진대회를 하면서 나름 얻는것도 많았고 생각할 것들이 많았던것 같아 의미있었던 프로그램이였다고 생각이 든다.
항상 모임이 있을때마다 자발적(?)으로 도와주시는 자원봉사자 분들과 사진을 공유해주신 현진님, 그리고 운영에 힘쓰시는 윤표님께 감사드리고 이날 발표하신 모든 분들과 참석하신 분들께도 고맙다는 말 전해드리고싶다.

나는 이번 모임에서 처음으로 발표를 했다.
여러 같은 UI개발자들과 함께하는 자리에서 발표를 해야 하는것이 떨리기도 했지만 평소에 잘 지켜지지 않고 있는 고질적인 문제들을 함께 공유하고 스스로가 고치기로 마음 먹는다는 다짐을 하는 취지에서 발표를 하게 되었다.
미투데이 웹 접근성 발표

처음엔 행사 후기만 기록하려고 했으나 내 발표 내용을 자료로 활용하기에는 이미지 위주이기 때문에 이해하기가 힘들것 같아 간략히 정리해서 공유를 하려고 한다.
이날 내가 준비한 발표는 내가 UI개발을 하고 있는 서비스인 미투데이에 대한 웹 접근성에 대해 다루었고, 미투데이라는 서비스가 얼마나 웹 접근성을 잘 지키고 있으며, 지키지 않는 부분이 있다면 어떤부분이고 왜 지키지 못하고 있는지에 대한 내용이다.

발표 내용 요약

미투데이는 블로그와는 조금 다른 가볍게 한마디 정도의 말을 기록하며 사람들과 소통하는 공간이다.
무조건 공개가 목적이고 누구든지 볼 수 있고 누구라도 사용할 수 있는 공간이기 때문에 어느서비스보다도 접근성과 사용성이 좋아야 할 공간이기도 하다.
W3C의 WCAG2.0에 나와있는 기준대로 접근성을 준수하기란 어려울 수도 있지만 한국에는 K-WAH3.0과 같은 접근성 평가 도구가 있기 때문에 어느정도 최소한의 접근성을 준수 하기 위해 도움을 받을 수 있다.
또한 이전 버전인 KADO-WAH2.0 과 최신 버전인 K-WAH3.0에는 도움말이 포함되어 있는데 WCAG1.0과 2.0 그리고 인터넷 웹 콘텐츠 접근성 지침에 대한 내용을 볼 수 있어 많은 도움이 된다.
실제 실무에서 웹 접근성을 지키자고 하면 많은 부서들과 커뮤니케이션이 필요하다. 왜냐하면 웹 표준과는 또 다르게 웹 접근성은 아직까지 일반인들에게는 생소한 느낌일 것이기 때문이다. 그렇지만 적극적으로 이해를 도와주고 설득해서 주변에 많은 동료를 만든다면 웹 접근성을 잘 준수시키는 사이트를 만드는데 그리 외롭거나 어려움은 없을거라 생각한다.
미투데이는 실제로 K-WAH3.0으로 검사를 하면 그다지 좋은 결과를 확인하지 못한다. 많은 사이트에서 비슷한 문제가 있을거라 생각되지만 일단은 UI개발자들이 조금 더 부지런해야 할 것 같다는 생각이 든다.
다음 세가지는 특히 준수하기 위해서 노력을 하도록 하자.

  1. 이미지의 대체텍스트 준수 같은 경우는 반복되는 이미지가 많기 때문에 자칫 한가지를 못지켜도 마치 준수율이 많이 떨어지는 느낌을 주기 때문에 반드시 지켜야 할 것이다.
  2. 서식과 label의 연결은 사용성과도 연관되기 때문에 개발자에게도 전달이 되어야 하며 서비스가 되기 전까지 점검을 해야 할 필요가 있는 항목이다.
  3. 링크와 form의 action URL은 Javascript를 이용한다고 해도 대체 페이지로 이동할 수 있도록 마련해 줘야 하며, 이것은 기획단계에서부터 먼저 준비가 되어야 하며 그렇지 않으면 서비스에서는 잘 적용하기가 힘들다.

접근성 준수를 위해 올바른 마크업을 사용해야 하는 것이 기본이겠지만 만약 이미 서비스 되고 있는 것을 마크업 구조까지 변경하기란 쉽지가 않을 것이다. 구조 변경으로 인해 다른 문제가 발생할 수도 있기 때문이다.
그렇기 때문에 접근성 준수를 HTML과 CSS만으로 해결하기보다 최소한이지만 조금이라도 더 배려할 수 있는 방법을 찾는 것도 하나의 방법이라 할 수 있다. 예를들면 입력 폼의 fieldset 제공이나 컨트롤러에 title만이라도 제공한다면 최고는 아니지만 최소한의 접근성은 배려할 수 있기 때문이다.
웹 접근성은 사람이 사람의 생활을 편리하게 하는 행위중에 하나이다. 누구도 쉽게 할 수 없는 일을 할 수 있다는 것에 전문의식과 자부심을 가지고 좋은 사이트가 많아질 수 있도록 모두 힘 내주었으면 좋겠다.

발표 자료 - 미투데이 웹 접근성

me2DAY 지금무슨생각해?

이번 me2day flickr 연동 문제와 관련해서 flickr의 web2.0이란건 어쩌면 달면 삼키고 쓰면 뱉는게 아닐까 싶은 생각이 든다.

flickr라는 서비스는 웹을 통해 사진을 업로드 하는 온라인 디지털 앨범이라는 서비스로 전세계의 사용자와 다양한 사진을 업로드하고 공유하자는 취지가 담긴 서비스라고 생각된다.

미투데이 flickr 사진 연동

미투데이 서비스는 이런 flickr을 통해 사진업로드를 제공받고 등록된 사진데이터는 미투데이 서비스를 거치지 않더라도 flickr 서비스에서 다른 사용자들이 구경할 수 있고 의견도 달수 있는 장점이 있어 그로 인해 다른 네트워크가 형성되고 관심사가 추가되면서 발전되는 형태로 나아갔고, flickr서비스가 추구하는 방향 역시 flickr웹사이트를 통해서만 사진 데이터를 이용할 수 있는 것이 아니라 공개된 API를 통해 다양한 방법으로 활용이 가능하도록 제공했고 지금도 달라진 것은 없다고 생각된다.

이런 서비스에 집단지성이라는 개념을 적용하면서 사진이라는 하나의 주제(데이터)에 대해 여러 종류의 태그가 붙게 되고 이 데이터에 여러 사람들이 연관된 태그를 연결시켜 다른 사람들과 데이터를 공유하는 방식을 적용하고 있으며, 이런 점이 Flickr가 생각하는 web2.0 이라고 생각 되지만 Web2.0 서비스의 참여, 공유를 바탕으로 생각해본다면 자발적인 참여와 활발한 활동을 추구하는 flickr에서 미투데이 계정 차단 이라는 결론을 보고있자면…
매우 유감이라고 표현하고 싶네..

Flickr의 황당한 대응에 모든 상황에 확신이 없어진다..내가 뭘 잘 못 알고 있는걸까..
난 그저 몇일전 flickr 프로 계정 결제가 아까울 뿐이다…에라이..
오늘을 기억해야지..

미투데이 서비스는 글쓰기를 개편하면서 처음 글을 쓰려는 사용자의 사용성을 더 편하게 하고, 접근성을 높이기 위해 노력중이다.
개선사항 중 입력폼의 비쥬얼 적이면서도 실용도를 높일 수 있는 기능들을 탑제하다 보니 작게 만들어 놓거나 기능이 사용되고 실체는 드러나지 않게 배경색 위에 위장해 놓은 부분이 Webkit 계열(safari, chrome)브라우저 에서는 포커스가 위치하면서 실체가 들어나 버리게 된다…
(이런 테두리의 압박이…)

outline 예제

그래서 뭔가 저런 시스템 적인 기본기능처럼 보이지만 없앨 방법이 있지 않나해서 찾아보니 이런 경우엔 css2 스팩에도 있지만 IE에서는 지원하고 있지 않는 속성인 outline 속성으로 간단히 없앨 수 있었다.
코드는 아래와 같다.

textarea, input {
outline-color:-moz-use-text-color; outline-style:none; outline-width:medium;
}

참고로 위 속성을 사용하면 outline 속성이 firefox 에서도 적용되기 때문에 outline-color:-moz-use-text-color; 속성으로 색상을 지정해 줘야 한다.

그리고 추가로 사파리나 크롬에서 textarea 의 사이즈를 사용자가 마음대로 조절할 수 있는데 만약 이 기능을 막으려면 아래 코드를 넣어 간단히 제어할 수 있다.

textarea {
resize:none;
}

입력 폼 컨트롤러에 대한 제어는 일부 사용자의 입장에서는 다소 민감한 부분일 수 있다. 어떤 곳에서는 오히려 좋은 기능이 될 수 있으니 서비스에 맞게 사용하면 좋을 것 같다.

2006년 12월 즈음 IE7이 출시되고 있던 것으로 기억된다.
(아마도 beta기간이 아니었나 싶다..)
당시 내가 속한 회사에서 제작 중이던 웹 사이트는 링크의 url을 기본적인 사이트 주소를 넣거나 #에 name을 붙여서 이동 하게 하거나 javascript로 이동하는 링크를 사용 했었다. 아마 대부분의 사이트에서 페이지 이동이나 컨텐츠 이동을 이렇게 하지 않았을까?

Link의 Pseudo Class :visited
IE가 아닌 브라우저를 이용해 웹 페이지를 제작해 본 사람이라면 링크의 url 경로가 스크립트로 구성 되어 있으면 :visited style이 적용 되지 않는다는 것은 잘 알 고 있을 것이다.
link의 pseudo-class중 :visited란? user agents에서 한번이라도 방문을 했는지 안 했는지를 구분하여 방문 하지 않은 페이지라면 :link로 인식 할 것이고 방문했다면 :visited로 인식하는 것을 말한다.(방문여부는 IE6 이하에서는 javascript 로 넘기는 링크라도 :visited를 인식하는 것을 보면 브라우저마다 기준이 다르지 않을까..?)

그렇다면 방문기록이 남을 수 없는 javascript로 이동한 경로는 그렇다 치더라도 #name으로 이동한 페이지는 방문 기록이 남게 된다.
웹사이트 방문기록 리스트
정상적이라면 방문기록과 href 의 url값을 비교하여 같다면 :visited로 인식이 되어야겠지만 IE7은 그렇게 되지가 않는다. 왜 그럴까?
그 당시 CDK에 글도 올려 보고 여러 사람들과 논의도 해 봤지만 그다지 중요하다는 생각이 들지 않는지 소리소문 없이 사라져 버렸는데 최근에 다시 듣게 되어서 정리하게 됐다.

CDK의 글을 보면 MS고객문의 답변 내용이 있는데 그 당시에는 답변에 대해 정확하게 정리가 되지 못하다 보니 고객문의 글을 100% 이해하기가 힘들었다. 특히 design이라는 단어가 뭘 뜻하는지 전혀 몰랐던 지라.. 그대로 묻혀 버렸는데 IE8에서도 동일하게 발생하고 있다 기에 다시 문의를 해본 결과 조금은 더 상세하게 답변을 들을 수 있었다.

답변 내용은…

[제목]
IE7: script에서 css visited 속성 사용할 수 없음.

[요약]
IE 7.0에서 CSS a:visited 속성을 기술해 주어도 href 에 # 이 들어가거나 javascript:xxx 형식으로 기술되면 기술된 속성이 반영되지 않아 색깔 구분이 안됨
샘플예제
<style> a:visited { color:blue } </style> <a href=”a.htm”> <– 정상동작
<a href=”javascript:showDetail(’b.htm’)”> <– a:visited CSS 반영안됨
<a href=”#b” onclick=”javascript:showDetail(’b.htm’)”> <– a:visited CSS 반영안됨

[원인]
Internet Explorer 7 의 강화된 보안 디자인으로 인한 현상으로, IE7 에서는 script 내에서 url history 정보를 보지 못하도록 디자인 변경되었습니다.
이로 인해 script 에서 CSS style 의 visited 속성이 적용되지 않는 것입니다.

[해결 방법]
고객사에서 관련 코드 수정하여 문제 해결.

제목이 script 사용으로 :visited가 안된 다고 되어 있지만 #이 들어도 마찬가지다.
좀 더 내용을 추가하자면 스크립트를 이용하여 이전 history 정보를 악용한 악성 사례들이 있어서 IE7 부터는 의도적으로 막았다고 한다.
자주 일어나는 일이 아니라서 잊혀져 있었던 일인데 원인을 확실히 알게 되어서 좋지만 이런 이유로 #name으로 이동하거나 링크 이동 후 자동으로 위치로 이동하기 위해 사용했던 링크 주소 방식은 방문기록에는 남지만 :visited로 인식하지 않는다니 아쉬움 생긴다.

해결방법?
IE에서는 보안정책이 강화되어 바꿀 수 없다고 하니 코드방식을 바꿔야 하지만 원천적으로 경로#name 을 인식하지 않게 되었으니 :visited를 인식할 수 있는 방법은 없을 것 같다
MS에서 제공해준 해결 방법이 있지만 사용하고 싶지 않은 건 나 뿐일까….;;

- Next »