NARADESIGN

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


Flash Navigation & Accessibility.

본문 건너 뛰기

WCAG 2.0이 2008년 12월 11일 정식 권고안이 되었습니다. Flash Navigation의 접근성에 관하여 이해하려면 일단 키보드 관련 지침을 이해하여야 합니다.

Guideline 2.1 Keyboard Accessible: Make all functionality available from a keyboard.
가이드라인 2.1 키보드 접근성: 모든 기능을 키보드로 사용할 수 있도록 만들것.

아주 단순하고 이해하기 쉽지만 잘 지켜지지 않는 지침 입니다. 왜 그럴까요? img 요소에 onclick 이벤트를 넣어서 키보드가 원천적으로 접근할 수 없도록 하는 Javascript 오남용 사례도 적지 않지만 Flash의 접근성에 대한 이해가 부족한 것도 대표적인 원인 가운데 하나 입니다. 

제가 키보드 접근성이 잘 지켜진 웹 사이트의 혜택을 처음으로 누린것은 1998년 가을 무렵 이었습니다. 당시 저는 병역의무를 마치고 다니던 대학에 다시 복학을 했는데 저보다 한 한기 먼저 복학한 동기녀석들은 제게 ‘한메일’ 사용법도 알려주고 학교 구석구석 비치된 ‘공용 PC’ 사용법도 알려주었습니다. 학교 곳곳에 비치된 PC는 매우 인기가 많아서 한 자리 차지하기가 쉽지 않았는데요. 어쩌다 하나 남은 빈 자리를 발견하고 달려가 앉을라 치면 역시나 볼 마우스가 고장인 경우가 많았습니다. 그럴때마다 저는 다시 자리에서 일어나야만 했는데 하루는 컴퓨터 공학을 전공한 친구가 새로운 사실을 알려주더군요. 마우스 없이도 PC와 인터넷을 사용할 수 있다구요. 그 친구는 보란듯이 키보드만으로 ‘넷스케이프’ 브라우저를 연 다음 ‘한메일’ 에 로그인도 하고 메일도 확인하는것을 보여주면서 마우스가 없이도 사용할 수 있도록 이 모든것이 설계가 되어있다고 하더군요. 이 사건이 제가 웹을 처음 접하던 시기에 격은 일입니다.

하지만 지금 똑같은 상황이 다시 벌어지게 된다면 어떨까요? 저는 다시 복학을 했고 마우스가 고장난 PC에 다시 앉아 있다고 칩시다. 그 친구는 여전히 제게 ‘마우스가 없이도 사용할 수 있도록 이 모든것이 설계되어 있다’고 말할 수 있을까요? 확신컨데 그렇게 말할 수 없었을 것입니다. 웹은 더 이상 옛날같지 않고 장애상황에서 사용하기는 더 어려워 졌습니다.

Flash 도구 자체가 접근성이 그렇게 나쁜것은 아닙니다. Flash도 키보드 접근을 고려하여 설계할 수 있고 심지어 화면낭독기가 대체 문자를 읽어주기까지 합니다. Adobe에서 제공하는 설명에 따르기만 한다면 말이죠.

Flash Accessibility Panel (Shift+F11)

지금 보시는 이미지는 Flash의 Accessibility Panel(Shift+F11) 입니다. ‘버튼 심볼‘ 또는 ‘무비클립 심볼‘에 위와 같은 접근성 속성을 입력할 수 있습니다.

Make object accessible :
객체에 접근 가능하도록 만듬.
Make child object accessible :
자식 객체에 접근 가능하도록 만듬.
Name : 
짧은 대체 텍스트.
Description :
긴 대체 텍스트.
Shortcut :
접근키로써 HTML의 accesskey 속성과 같은 역할을 합니다.
Tab index :
탭 순서로써 이를 설정해 두지 않으면 네비게이션의 구조와 관계없이 배치된 위치에 따라서 키보드 접근 순서가 결정되기 때문에 가능한 사용하는것이 좋습니다.

브라우저 호환성 문제가 해결되지 않음

하지만 모든 브라우저에서 이것이 가능할까요? 라고 물어오신다면 아직 아닙니다. 현재는 MS IE 브라우저에서만 키보드로 접근이 가능하며 다른 브라우저(FF, OP, SF, CR)에서는 키보드만으로는 Flash에 접근할 수 없습니다. 이것은 Adobe측에서 배포하는 Flash Player가 아직 브라우저 호환성 문제를 해결하지 못했기 때문인 것으로 알고 있습니다. 이 문제가 Adobe 측에서 풀어야 할 문제인지 Browser 벤더들이 해결해야 할 문제인지 정확하게 잘 모르겠네요. 혹시 아시는게 있으시면 코멘트 부탁드립니다.

화면낭독기를 지원하지 못할 수 있음

Adobe가 안내하는 접근성 관련 Flash 제작 지침에 따랐다 하더라도 Flash를 HTML 문서에 삽입하는 형태에 따라서 화면낭독기의 접근이 불가능하게 됩니다. object 요소 안쪽에 작성하는 param 요소에 다음과 같이 wmode를 transparent 또는 opaque로 설정하게 되면 화면낭독기를 지원할 수 없습니다.

  • <param name="wmode" value="transparent" />
  • <param name="wmode" value="opaque" />

결국 Flash를 HTML 문서에 삽입할 때에는 다음과 같이 wmode가 window 상태여야 한다는 의미 입니다.

  • <param name="wmode" value="window" />

Flash는 Navigation 요소로써 접근성이 떨어짐

결국 저는 Flash가 Navigation 요소로써 더 이상 사용되지 않아야 한다고 주장합니다.

  1. 첫째, 접근성 지침에 따라 정교하게 만들어 졌다 하더라도 HTML 문서 삽입 방법에 따라 화면낭독기가 읽을 수 없는 상태가 되고.
  2. 둘째, 화면낭독기가 읽을 수 있는 상태가 되더라도 키보드 접근 가능성은 어디까지나 MS+IE 사용자에게만 돌아가는 혜택이기 때문입니다.

Adobe가 이 문제를 해결하기 전까지 Flash Navigation 콘텐츠는 접근성이 떨어지기 때문에 사용해서는 안된다는 비판을 피할 수 없을 것입니다.

참조

분류: 웹 기획,웹 디자인,웹 접근성 | 2008년 12월 27일, 6:44 | 정찬명 | 댓글: 35개 |
트랙백URI - http://naradesign.net/wp/2008/12/27/426/trackback/

35개의 댓글이 있습니다.

  1. 양주일 댓글:

    그럼 플래시와 같은 Rich한 기술은 애니메이션 위주의 구성만 해야 할까요? 요즘 컨텐츠 자체, 웹어플 자체에 네비게이션 요소가 없는 게 있을리 만무하잖아요?
    FF에서도 안된다고 하니 컨텐츠 요소로도 쓰면 안되겠네요. 그리고 진정 IE와의 호환성만 있다고 한다면 기업과 재단의 차이로 인한 협업 관계와 각각의 제품 차이로 인한 무언가 충돌(기능을 추가하지 못했던 이해관계)이 발생하진 않았을까요? 그런 것도 제고해봐야 한다고 보입니다.

  2. 봄눈 댓글:

    찬명님 글 잘 일었습니다^^ 요즘 많이 포스팅 하시네요~ 오픈캐스트 베타테스터라서 종종 웹표준 관련된 글들을 수집해서 올리는데, 서너번 하다보니 소개할만한 글들이 점점 부족해지고 있었는데 찬명님이 이렇게 자주 올려주시니 가뭄 속에 단비가 내리는 것 같아요 ㅎㅎ 앞으로도 좋은글과 내용 부탁드릴게요~

  3. 정찬명 댓글:

    장애상황과 장애인에 대한 접근을 포기하는 대신 플래시를 사용하면서 얻을 수 있는 혜택이나 그 가치가 더 크다고 한다면 사용하는데 주저할 일이 없다고 생각 합니다.

    하지만 현재까지는 가치판단을 하는 가운데 접근성에 대한 가치를 저울 한쪽에 올려놓고 다른 가치와 재어 보는일조차 제대로 진행되지 않았다는 생각이 듭니다.

    플래시를 네비게이션 요소로써 사용하지 않아야 한다는 제 주장이 일면 극단적인 표현이 되었을 지언정 하루 아침에 그렇게 되기를 기대하지 않으며 단지 기존에 고려하지 않았던 가치들이 앞으로는 고려되기를 바라는 관점에서 작성 하였습니다.

    의견 감사드립니다. (__) 즐거운 주말 되세요!

  4. 정찬명 댓글:

    봄눈님 오픈 캐스트는 레퍼러 통해서 방문한 적이 있습니다. 일주일에 한번씩 방문할 예정입니다. 꾸준히 알차게 부탁드려요! ㅎㅎ.

  5. 미희 댓글:

    IE에서 플래시상에 tabindex를 정한 후 html 상에서 tab키로 이동 테스트를 하다보면 html 상에서 tabinex가 없으면 플래시와 컨텐츠 순서를 제대로 이동하지만, 문서상 tabindex가 지정되어 있는 경우는 잘 안 되었던 것이 기억이 나 글 남겨봅니다. 아.. 좀 뜬구름 잡는 식의 질문이 되어버렸네요 ^^;;

    네비게이션 플래시로 제작에 대해서는 반대로 ‘왜 네이게이션은 플래시로 만들어야 할까?’ 라는 질문을 스스로에게 던져보기도 했지만요. 우리가 단순히 눈에 보이는 것을 쫒거나, 당연히 플래시로 해야하는거 아냐 란 식으로 개발이 되어진건 아닌가에서 출발한 것 인데요. 물론 상황과 사이트 성격에 맞게 고려해서 제작되어야 하겠지요. 접근성 외에 사용성의 측면에서도 메뉴 구동 및 클릭영역에 대해서도 학습을 통해 익숙해져서 불편한 것을 못느끼게 된 건 아닌가 하고요. 플래시도 그 능력을 제대로 발휘 할 수 있게 쨔쨘 하고 호환성이 좋아지면 좋겠습니다 크으 (_ _)*

  6. 정찬명 댓글:

    코멘트 감사합니다. 평소에 HTML 문서에서 tabindex는 되도록 사용하지 않는것이 좋다는 주장을 뒷받침하는 또 다른 근거가 되겠네요. ‘쨔쨘’ 하고 좋아졌으면 하는 바램 저도 가져 봅니다.

  7. 리거니 댓글:

    새로운 기술을 무조건 사용하지 말아야 한다고 하기 보다는 현재 상황을 개선할 수 있는 방법을 찾아보는 것도 좋은 접근법이 될 거라고 생각됩니다.

  8. 리거니 댓글:

    참고로, 실버라이트와 WPF에서도 접근성 지원 기능이 있어요.
    http://blogs.msdn.com/eva/archive/2008/12/14/silverlight-wpf-accessibility.aspx

  9. 리거니 댓글:

    웹에서 RIA 기술을 이용하여 웹애플리케이션 형태의 서비스를 구성하는 것은 사용자 중심으로 변화하는 웹 전반의 추세라고 생각합니다. 과거 “네비게이션”이라고 불렀던 웹사이트의 일부 요소로써의 RIA 기술이 아니라, 이제는 사용자에게 그 이상의 가치를 줄 수 있는 “애플리케이션” 으로써 RIA 기술이 주목받고 있는 것처럼요. 그래서 접근성 원칙을 위에 두고 RIA를 거부하기 보다는, RIA 기술 위에서의 접근성 지원에 대한 논의가 더 활발하게 되어야 한다고 생각합니다.

  10. 정찬명 댓글:

    이 기술을 사용하지 말아야 한다는 주장 속에는 항상 ‘이 문제가 해결되기 전까지는…’라는 전제가 깔려 있습니다. 이 기술을 무조건 반대하거나 거부하는 것이 아닙니다. 신 기술이 주는 이로움을 잘 알고 있지만 ‘보편성’을 갖추지 못한 기술이 그것을 갖출 때까지 저와 같은 주장은 한쪽에서 계속 되어야 한다고 생각합니다.

    웹에서 어떤 기술을 사용하든 그 기술을 이용하는 사람의 ‘가치판단’ 속에 ‘보편성’에 대한 가치가 배제되어서는 안된다고 생각하기 때문입니다.

  11. 정찬명 댓글:

    Flash & Accessibility 라는 주제를 전문적으로 다루는 블로거가 있네요. ^^
    Niqui Merret – http://niquimerret.com/

  12. 정찬명 댓글:

    Niqui Merret에 의하면 IE 이외의 다른 브라우저에서 플래시 객체로 키보드 접근이 되지 않는 것은 브라우저 제조사들이 풀어야 할 문제라고 말하고 있는데 정말 브라우저 제조사에게만 책임이 있는 것인지 궁금하군요.

    그리고 더불어 드는 생각은 Flash 접근성을 향상시키는 일이 검색엔진의 크롤링 가능성과도 전혀 무관하지 않군요. Flash 콘텐츠에 대한 접근 가능성이 높아질수록 기계가 인식하기 쉬워질테니까요.

  13. 김주원 댓글:

    flash10 업데이트로 젤롱보드의 첨부기능이 먹통이 되었다는 사실을 어제서야 알고
    예전에 지인에게 만들어준 홈페이지를 부랴부랴 버전 업데이트했더랍니다.;;

    플래시컴포넌트이기에 그럴수 있겠다 했지만
    생각해보니 버전 업데이트 할때마다 이런다면 큰 문제다 싶더군요.

    첨부 멀티업로드는 플래시컴포넌트 & ActiveX 아니면 안되는건지….

    딴소리만 하구 가네요.ㅋ 수고하세요~

  14. 정찬명 댓글:

    딴소리라뇨. 저도 그부분을 무척 아쉬워 하고 있습니다. ㅜㅜ; 안타깝게도 이미 배포된 기능이라 섣불리 플래시 컴포넌트를 빼자는 의견을 못내고 있을 뿐이죠. 멀티업로드 기능의 편의를 체험한 분들께서 제 의견에 반대할 것이 명백하고 접근성을 확보해야 한다는 주장 아래 그 유용함을 제한하는 것도 확실히 옳은 일이라고 말하기도 어려운 것 같습니다.

    따라서 이미 적용한 기능은 어쩔 수 없지만 아직 적용되지 않은 분야에 대하여는 지속적으로 관심을 갖고 의사결정 과정에서 어필할 예정입니다. 지금 제가 할 수 있는 최선은 제 의견을 관철시키는 것보다 새가 좌우의 날개로 날 수 있도록 한쪽 날개를 퍼덕이는 일 같습니다. 체념하는 것은 아닙니다. 한걸음씩 나아하려고 하는 것 뿐이죠. ^^

  15. 미소챨스의 생각…

    Flash Navigation & Accessibility. …

  16. 임진철 댓글:

    예전에 프로젝트하면서 플래쉬가 Tab Key 이동이 되지 않아 고생했던 적이 있습니다. 결국 메인홈페이지는 플래쉬를 모두 빼고 어린이 홈페이지에만 플래쉬를 적용했습니다. 어린이 홈페이지에 대해서도 논의가 많았는데, Tab Key 이동이 가능함으로써 누릴 수 있는 이점보다 플래쉬를 뺌으로써 손실되는 점이 더 많다라고 판단해서 어린이 홈페이지에는 적용을 했습니다.

    실제 프로젝트를 하면서 느끼는건데 접근성이라는 것은 정책과 기획이라는 생각이 듭니다. 접근성 지침은 있지만 실제 그것을 어떻게 해석하고 어떤 식으로 정책을 세울 것인지를 먼저 정하고 접근해야 한다는 생각입니다.

  17. 정찬명 댓글:

    네, 옳으신 말씀입니다. 한편 정책을 세우는 과정에서 수혜자의 범위와 법률에의 저촉여부등을 면밀하게 검토해야 나중에 문제가 되지 않겠지요.

  18. […] 물론, 2002년부터 배포되기 시작한 플래시MX는 시각장애인의 접근성을 고려한 일정한 장치가 있긴 하다. 그러나, 그러한 장치가 실제로는 시각장애인에게 별 도움이 되지 못한다는 점은 실증적 연구를 통해서 이미 밝혀진 바 있다. 여기. 국내의 정상급 개발자 분들도 이 문제를 소상히 논의하고, 설사 플래시MX를 사용하고, 그것이 제공하는 접근성 기능을 모두 활성화 하더라도, 플래시는 시각장애인에게 여전히 장애물이라는 점을 안내하고 있다. 여기. […]

  19. 누리 댓글:

    안녕하세요. 웹접근성 공부하고 있는데 궁금한 점이 있어서 글 남깁니다..
    flash navigation을 만들었는데 wmode가 window로 넣을 수 없는 구조라면 어떻게 해야하는지요? 가령 navigation 아래 visual 또는 content가 겹쳐서 보여야 할 경우 말이죠..
    visual 부분과 navigation과 함께 합쳐서 하나의 movie로 만들어야 할까요? 아님 navigation을 이미지로 만들어야 할까요.. 잘 모르겠어요..T_T

    그리고 공공기관 사이트를 보면 화면크기조정(+ – 초기화)이 있는데 flash 삽입시 wmode를 window가 아닌 opaque, transparent로 넣고 화면크기에 변화를 주면 원래 있던 위치에서 벗어나 버리는데 이것 또한 wmode가 window가 아니라 영향을 받는걸까요?

  20. 정찬명 댓글:

    만약 저라면 일단 플래시를 사용하지 않는 방법을 고려하고 플래시를 사용할 수 밖에 없다면 배경 이미지를 플래시 안에 포함시킨 후 wmode를 window로 처리하겠습니다.

    그리고 화면크기 조정과 관련하여 배치가 깨지는 부분은 저도 잘 모르겠습니다. 간단하게 wmode를 window로 바꿔서 테스트 해보시면 그것의 영향을 받는지 여부를 알 수 있지 않을까요? ^^

  21. 누리 댓글:

    역시나 그 방법밖엔 없나봐요.
    화면크기 관련은 wmode를 window로 바꿔서 하면 되구요. 이것 역시 영향을 받나보네요.
    접근성의 길이 멀게만 느껴졌었는데..답변 감사합니다~^^

  22. 정지영 댓글:

    플래시 네비게이션이 xml방식이라면 어떻게 tabindex를 적용시킬 수 있을까요?
    플래시에서 적용시켰더니 아무 반응이 없네요. xml소스에서 tabindex를 적용시켜 줘야 할 것 같은데 아무리 검색해 봐도 답이 안나옵니다. 혹시 이부분에 대해 알고 계신다면 도움 부탁드립니다.^^

  23. 정찬명 댓글:

    제가 잘 모르는 부분이라서 참조 문서 하나만 걸어 드립니다.
    http://help.adobe.com/ko_KR/Flash/10.0_UsingFlash/WSd60f23110762d6b883b18f10cb1fe1af6-7c4aa.html

    혹시 웹 접근성 연구소쪽에도 동일한 자문을 올려 보셨는지요?
    http://www.wah.or.kr/Consulting/consultList.asp

  24. 정지영 댓글:

    제가 웹 접근성 쪽은 아직 입문단계라 웹 접근성 연구소에 자문을 구하는 방법을
    생각하지 못했네요. ㅎㅎ 답변 너무 감사드립니다!

  25. 신오수 댓글:

    웹접근성 연구소에서 정찬명위원님 글을 읽고 블로그을 찾아 들어와서 글들을 읽어보고 개인적인으로 많은 도움을 받았는데요… 감사드리구요…

    지금 제가 플래쉬 메뉴에서 가장 중요한 메뉴 하나하나을 스크린리더기가 읽어 내는 부분이 가장 중요한 생각이 되는데요..
    Accessibility을 이용해서 제가 작업을 해본 결과.
    센스리더에서 마우스을 올린경우 한메뉴을 2번씩 읽어 버리는 경우가 발생을 하더라구요..
    제가 개인적으로 센스리더개발자랑도 대화을 해봤는데..특별한 답변을 못들었구요.
    그래서 제가 시험을 해본 결과 Accessibility에 네임 부분을 한번 읽고 메뉴 자체가 플래쉬에서 텍스트 버전(static text상태)로으로 남아 있는경우 센스리더의 경우 읽어주는 것을 알 수 있었습니다.
    결과적으로 따지면 텍스트 버전(static text상태)로 메뉴가 되어 있다면 구지 Accessibility에 네임값을 주지 않지 않아도 된다는 결론을 얻었는데요..
    드림보이스도 텍스트 버전(static text상태)는 메뉴을 하나하나 읽어줌
    제 생각이 맞는지 궁급합니다.
    http://203.240.248.11/IS/web/index.jsp
    이사이트에서 보면 상단메인메뉴는 텍스트 버전(static text상태)로 Accessibility에 네임값을 따로 주지 않았습니다. 드림보이스나 센스리더에서 그냥 메뉴을 하나씩 읽어주는 확인 가능 하실겁니다.
    그리고 메인 메뉴에 제가 swit와 함게 발전하는 e-사회는 Accessibility에 네임값을 준 형태입니다.
    그리고 플래쉬는 ie을 을 제외하고 tab 값이 안 먹힌다고 위에서 설명 했던거 같은데요..
    다른것들은 안 먹는게 맞는데 파이어폭스는
    이런식으로 object 안에 tabindex값을 주니깐 tab이 플래쉬도 먹히는 것을 확인할수가 있었는데요. 이부분 의견도 좀 듣고 싶습니다.

  26. 신오수 댓글:

    (수정합니다.)
    그리고 메인 플래쉬이미지에 제가 swit와 함게 발전하는 e-사회는 Accessibility에 네임값을 준 형태입니다.

  27. 정찬명 댓글:

    신오수님 안녕하세요?
    플래시에서 static text에 관한 자료를 찾아보니 웹 접근성에 대한 연구 자료가 많은 WebAIM 이라는 사이트에 이런게 있네요. 플래시에서 static text를 사용한다면 아무런 별도의 수정 없이도 화면낭독기가 읽어준다는 설명 입니다.

    http://www.webaim.org/techniques/flash/text.php#how

    If your Flash movie is nothing more than static text, then it will probably be accessible to screen readers without any other modifications. Of course, Flash is rarely used to display static text. While text elements do not require modification by the designer/developer, other elements do.

    tabindex=”0″ 속성에 키보드가 접근하게 되는 것은 다소 변칙적인 방법이긴 하지만 다른 브라우저에서 키보드 순서에 영향을 미치지 않으면서 FF 브라우저에서도 키보드로 플래시 객체에 접근이 가능하도록 하는 방법인것 같습니다.

    향후 등장하는 브라우저들이 tabindex=”0″ 을 해석할 때 문제가 되지 않는다면 사용해도 좋다고 생각합니다.

  28. 다락방고양이 댓글:

    좋은 내용 감사합니다. 큰 도움이 되었습니다. 트랙백 해 갈게요^^

  29. 플래쉬 네비게이션과 웹 접근성…

    어제 하루 종일 찾아 헤맨 주제였다. 역시 플래쉬의 사용과 웹 접근성에 대한 충돌은 아직은 불가피 할 듯. 지금 하고 있는 포트폴리오에선, 비쥬얼 플래쉬에 탭 키가 안먹힌다.-_- 그리고 자바 스크립트를 이용한 삽입과 object를 이용한 삽입 사이의 갭이나 정리 된 내용도 아직 못찾았다. 초보인 내겐 정말 어려운 부분이다 이건……

  30. 어제강의하시느라 수고 많으셨습니다.
    플래쉬에 Tabindex에 관한 부분인데요 플래쉬부분에 Tabindex=0를 넣어도 상관없는데 유독 오페라쪽에서 문제가 있어서
    제가 Tabindex를 넣지 않는 쪽으로 말씀드렸는데요
    아침에 와서 다시 한번 확인해 결과 오페라 자체가 키보드가 순차적으로 접근하지 못하고 input박스에만 키보드가
    접근하는 부분을 확인 했습니다.
    단, 오페라에서 키보드접근 가능한 사이트가 http://www.goeay.kr/경기도안양과천교육청인데요
    이사이트을 소스을 보면 모든 링크값에 Tabindex=0을 들어가 있는 것을 확인 할 수 있습니다.
    결과적으로 오페라에서는 모든링크값에 Tabindex=0를 넣어줘야 키보드가 순차적으로 접근 가능하며 오페라를 제외한
    모든 브라우저에서는 플래쉬소스안에 Tabindex=0을 넣어도 키보드 접근방식에 큰 문제가 없다는 것입니다.

    http://www.swit.or.kr/IS/web/index.jsp
    이사이트 자체가 플래쉬다음에 바로 로그인박스(input)가 있어서 제가 착각을 했습니다.

    그리고 http://www.swit.or.kr/IS/web/index.jsp 이사이트 들어가면 첫페이지에 팝업창이 있다는 알림창이 뜨는데
    이부분은 웹접근성 부분에서 큰문제가 없는지 확인 바랍니다.

  31. 정찬명 댓글:

    @d2ong@ibsolution.co.kr
    아 그랬군요. 그런데 오페라 브라우저는 원래 tab 키가 form 콘트롤만 탐색하게 되어 있고 링크 탐색은 ‘Ctrl+방향키, Shift+방향키’로 탐색하게 되어 있습니다. 따라서 오페라 브라우저를 위해 tabindex=0 값을 지정하실 필요는 없습니다.

    그리고 tabindex=0 의 사용은 표준 명세에 의하면 포커스를 갖지 못하고 건너 뛰어야 하는 값으로 확인 했습니다. 결국 브라우저는 tabindex=0을 건너 뛸 수 있기 때문에 권장하기 어려운 방법이라고 판단 합니다.

    * 참고자료 tabindex 속성 명세

    Those elements that do not support the tabindex attribute or support it and assign it a value of “0” are navigated next. (요소가 탭인덱스 속성을 지원하지 않거나 지원하되 값이 “0”인 경우 다음 요소를 탐색해야 한다.)

    원문 – http://www.w3.org/TR/1999/REC-html401-19991224/interact/forms.html#h-17.11.1
    번역문 – http://trio.co.kr/webrefer/html/interact/forms.html#adef-tabindex

    수업 들으시느라 고생도 많이 하셨고 도움도 주셔서 고맙습니다. ^^

  32. Ctrl+방향키, Shift+방향키’ 오페라에서 이부분을 제가 착각했습니다.

    플래쉬부분에 tabindex=0을 주면 오페라에서는 그냥 플래쉬부분을 건너뛰면 다음 순차로 잘 넘어갑니다.

    결과적으로 파이어폭스 때문에 tabindex=0을 줘도 다른 브라우저에서 큰영향을 미치지 않습니다.

    강의시간이랑 틀린 결과입니다.

    파폭때문에 tabindex=0을 써서 문제거리를 만들지 않는것도 나쁘지 않을듯 싶내요.

    http://www.swit.or.kr/IS/web/index.jsp
    이사에트에 첫페이지에 팝업창 때문에 alert창을 먼저 보여주는 방법은 접근성 부분에서 위배되는지 알고 싶습니다.
    우측에 보면 팝업창 보기가 버튼이 딸 존재는 하지만 클라이언트쪽에서는 바로 뜨는 것을 선호합니다. alert창이 틀리다면 다른 방법이 혹시 있나요?

  33. 잠시 다른문제가 있습니다.

    파이어폭스에서 플래쉬부분에 tabindex=0을 주면 플래쉬부분을 선택해서 각메뉴마다 선택을 잘하는데 플래쉬을 반복하는 현상이 일어납니다.

    결과적으로 플래쉬를 벗어나지 못하는 현상이 일어납니다.

    tabindex=0은 플래쉬에서 주지 않는것이 좋을 것 같습니다.

    자꾸 말을 바꿔서 죄송합니다.

  34. 정찬명 댓글:

    @d2ong@ibsolution.co.kr
    아, 그렇군요. 괜찮습니다. 직접 테스트 해보지 못해 궁금했는데 좋은 정보 알려주셔서 정말 감사합니다. ^^

  35. 정찬명 댓글:

    @d2ong@ibsolution.co.kr
    팝업창을 볼 것인지 미리 선택할 수 있는 alert을 제공하는 것은 분명히 선택권을 주었기 때문에 접근성에 문제가 된다고 생각하지 않습니다. 그러나 사용성이 떨어지는 방법이라 추천하기 어렵습니다. 저라면 초기화면에 팝업존을 추가할 것을 제안할 것 같습니다.

댓글 쓰기

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

필수 아님

필수 아님