ALT 와 Title 속성의 바른 의미

최근 CDK에 들렸다가 봄눈님의 "longdesc 쓰시나요" 의 글타래를 통해 alt 와 title, 그리고 longdesc 에 대한 의미적인 접근을 해보고 싶었습니다.

대체 텍스트의 ALT 는 이미지가 보여지지 않을시에 이미지를 대신하여 보여지는 문구 입니다. 툴팁의 목적으로 사용하는 것은 바른 방법이 아닙니다. Title은 필수 요소는 아니지만 base, basefont, head, html, meta, param, script, and title를 제외하고는 어느 곳에나 쓰여지며 삽입되는 부분에 대한 설명을 담당합니다. longdesc는 alt 가 길어지는 경우 제대로된 설명을 담은 외부문서 주소를 지정해 줍니다. 많은 브라우저들에서 지원되지 않는 longdesc 에 대한 토론은 CDK 에서 마음껏 나누실수 있습니다.

alt vs title

많은 경우 문제는 alt와 title 의 차이에 대한 선을 긋지 못함으로 비롯됩니다. 오래전에 북마크 해 두었던 alt와 title 에 대한 토론을 읽어 보셔도 아시겠지만 (결과가 나지 않아 아쉽더군요) 상당히 헛갈릴수 있는 어찌보면 자연스럽게도 보일수 있는 문제 입니다.

ALT 는 이미지가 출력이 인위적이든 아니든 출력이 되지 않았을 경우 이미지와 동일한 의미를 전달 하는 문서의 한 부분으로써 사용되는 것이며 title은 어떠한 이미지인지 설명을 담당 합니다. "동일한 의미"를 전하는 것과 "설명"의 차이는 무엇일까요. 말보다는 예가 빠르고 쉽겠습니다. 올해 여름 패션을 이야기하는 문서에 한 예로 흰 와이셔츠를 입은 남성의 사진을 첨부하는 상황에서 이렇게 이미지의 alt 와 title 이 구별될수 있습니다.

올해 패션은 깔끔하고 단조로운 스타일이 대세를 이룰것으로 보입니다. 더이상의 설명보다 이하의 사진을 보며 계속 나누겠습니다. img src="summerModel.jpg" title="정면으로 찍은 남성 모델 사진" alt="이 모델은 흰 와이셔츠와 진한 남색의 청바지를 입고 있습니다." 흰 와이셔츠는 깔끔하면서도 시원한 느낌을 전달하며 청바지는 ...

title은 이미지에 대한 설명을 하고 있고 alt는 이미지를 대체하는 즉 동일한 의미를 표현하고 있습니다. 하지만 아시다시피 대부분의 경우 img src="summerModel.jpg" alt="남성 모델 사진" 으로 끝이 나게됩니다. title과 alt가 뒤바뀐 것이죠.

위처럼 문서의 일부로써 사용되는 이미지가 있는가 하면 그다지 의미전달이 불필요한 이미지가 삽입된 경우도 있습니다. 예를들어 사파리 브라우저 이야기를 하기 위하여 사파리 로고를 문서위에 지정해 놓은 경우인데 이러한 꾸밈을 위한 이미지에 alt가 필수 요소이므로 "사파리 로고" 라는 문구를 넣기 보다는 alt="" 처럼 대체 텍스트를 오히려 비워 놓는것이 맞습니다. 문서를 정보로써 이해 하는데에 불필요할 뿐더러 브라우저 이외의 유저 에이전트가 접근시에도 무의미하게 "사파리 로고" 라고 읽혀지며 낭비하기 때문입니다. 저도 아무 생각없이 지정하는 실수인데 같이 고쳐가면 좋겠습니다.

더욱 분명한 선을 긋기 위하여 Ian Hicks (acid2, acid3 저자) 의 상당히 오래된 글인 "Mini FAQ About the Alternate Text of Images"를 번역하여 첨부하였습니다. 한국에서 특정 태그나 속성들의 정의나 토론들을 참고 삼을때 또한 소개할때 국내에 번역되거나 직접 쓰여진 글들이 적으므로 영어 사이트를 링크하는 경우가 대부분 처럼 보입니다. 해서 앞으로 기회가 될 때마다 레퍼런스로 삼을수 있는 참고가 가능한 글들은 저자의 허락 아래 번역하려 합니다.

원문: MINI FAQ ABOUT THE ALTERNATE TEXT OF IMAGES

글을 읽기 전에 이하의 노트를 참고 하시면 글을 이해하는데 더욱 편하실꺼라 생각됩니다.

  • 텍스트 = 문구, 글로 보시면 됩니다. 문구나 글 이라고 표현하지 않은 이유는 이미 한국 웹 개발자들 디자이너들 사이에 "대체 텍스트" 라고 알려져 있기에 굳이 글자 그대로 번역하지 않은 것입니다.
  • 인라인 이라는 개념은 텍스트와 동일한 문단안에 글 처럼 삽입되는 것입니다. 같은 줄에 위치한다는 개념으로 in line 으로 이해하시면 됩니다. 반대는 그만의 영역을 같는 블락 이겠습니다.
  • 제작자 - Author 를 제작자로 넣었습니다. 저자 가 더 나은 접근입니다만 한국말로 저자는 글을 쓰는 사람으로만 인식이 되어 있기 때문에 문맥상 혼돈 되는 부분이 있을듯 하여 굳이 제작자 라고 해석하였습니다. author 는 저자, html 을 쓴 사람, 문서를 제작 하는 사람 등등의 의미를 함축하고 있습니다.

이미지의 대체 텍스트 ALT 에 대한 FAQ

개요

Alt 속성은 대체 텍스트로 이미지가 보여지지 않을때 보여진다. 유저 에이전트는 이미지를 지원하지 않거나 특정 이미지 타입을 지원하지 않을때 혹은 이미지 출력을 꺼 놓았을때 이 대체 텍스트를 보여주어야 한다.

대체 텍스트는 단순히 "alternate" 대체 하는 것이다. 다른말로 하면 이미지의 의미를 문자로 표현하여 대체 하는 것이다. 이미지가 전달 하려는 것을 그대로 전달 하는 것이다.

제작자는 페이지의 형식을 위한 이미지들을 위해 무의미한 텍스트를 넣는 실수를 하면 안된다. 예를들어 붉은 공 모양의 이미지가 헤딩이나 문단을 꾸미기 위해 첨가 되었는데 alt="빨간 공" 이라는 대체 텍스트는 올바르지 않은 사용이다. 이러한 상황이라면 그저 빈 텍스트가 어울린다 (alt=""). 제작자들은 이전에 페이지 형식을 위한 이미지 사용을 피하기를 권한다. 스타일시트가 사용되어야 하겠다.

제작자들은 무의미한 대체 텍스트 삽입 또한 주의하기 바란다. (더미 텍스트 라고들 한다.) 유저들을 불편하게 할 뿐 아니라 글을 읽어주는 유저에이전트나 점자 에이전트를 느리게 할 뿐이다.

전형적인 주장들

만약 이미지가 빠졌다면 프레임(이미지 틀)이 제외되고 이미지와 똑같은 정보를 제공하는 인라인 텍스트로 대체 되야 한다고 생각한다. 그 텍스트가 바로 대체 텍스트로 alt 속성이 담고 있는 텍스트이다.

많은 사람들이 이미지가 보이지 않을때 이미지의 원래 틀(영역, 사이즈)은 유지되어야 한다고 주장한다. 이 글을 통하여 왜 그것이 불필요한지 설명할것이다.

주장 #1

"이미지의 생명은 영역이다"

이미지의 생명은 영역이 아니다. 오히려 그것의 의미이다. 이미지의 그래픽적인 표현의 요소는 (보통) 절대 필요한 것이 아니다. (예외를 예로 들자면 환영이나 착각을 목적으로 한 이미지가 있겠다. 그런 경우엔 이미지의 그래픽 요소가 절대 중요하겠다.(하지만 그 외에는 대부분 절대적이 아니다))

주장 #2

"내 생각엔 원초적으로 html 의 버그라고 본다. HTML 을 사용하여 제작하는 저자들에게 특정 이미지가 텍스트를 대체 하기 위해 사용한 것인지 아니면 텍스트의 부가물로 사용한 것인지를 구별 하라는 것은 말이 안된다."

모든 이미지들은 글을 replace 대체(교체) 한 것이다. 아니 오히려 텍스트와 이미지 둘 다 "의미"를 대체 한 것이라고 볼수 있다. 다시 말하면 둘 중 한가지가 언제든지 다른 한가지를 대신하여 "의미" 전달의 도구로 사용될수 있다는 것이다. 하지만 가끔은 둘중 한가지가 다른 것 보다 특정 의미를 전달하는데에 더 나을 수 있다.

주장 #3

"삽화(다이아그램)로써 어떤 이미지들은 보는 것이 천마디 말보다 나은 이미지들이 있다. 예를들어 이러한 alt 를 담고 있는 이미지 이다. alt="인디아나폴리스 학교의 Communicator 4.x 의 프록시 세팅을 보여주는 스크린샷" "

일단 그것은 절대 올바른 대체 텍스트가 아니다. title 속성으로는 좋을지 모르나 대체 텍스트로는 부적절 하다. 적절한 대체 텍스트로는 이런식일 것이다.

alt="Proxy 세팅 다이어로그 박스는 'proxy.i.edu' 를 'host' 필드에 담고 있고 모든 프로토콜에 3128 'port' 를 담고 있다"

그리고 이하의 페이지에 이러한 부분이 첨가 되어있어야 할 것이다.

**위의 스크린샷은 인디에나폴리스 켐퍼스의 Commnicator 4.x 프록시 세팅을 담고 있다.** 이미지는 인디에나폴리스 켐퍼스의 Communicator 4.x 어플리케이션의 프록시 세팅을 묘사하고 있다. 다이어로그 박스는 HTTP, FTP, GOPHER, HTTPS 의 4열의 수정가능한 박스들을 담고 있다. 각 열은 host 와 port 가 맨 위에 위치한 두개의 수정 가능한 박스들을 담고 있다.

각 'host' 필드는 'proxy.i.edu' 를, 그리고 'port' 필드는 3128 을 담고 있다.

이 페이지는 (설명이 기므로) <IMG> 태그에 "longdesc" 속성을 사용하여 연결되어 있어야 한다. 고로 이미지 태그는 이렇게 생겼을 것이다.

<IMG src="screenshot1.png" alt="Proxy 세팅 다이어로그 박스는 'proxy.i.edu' 를 'host' 필드에 담고 있고 모든 프로토콜에 3128 'port' 를 담고 있다" title="위의 스크린샷은 인디에나폴리스 켐퍼스의 Commnicator 4.x 프록시 세팅을 담고 있다." longdesc="screenshot1.desc.html" />

대체 텍스트 alt 가 이미지를 대신하였고, title은 간단한 description(caption, 묘사) 를 하고 있으며 longdesc 는 이미지의 긴 설명을 담당하고 있다.

다시말하지만 alt 대체 텍스트는 이미지를 DESCRIPTION 묘사하는 것이 아니다. 오히려 이미지의 의미 MEANING 전달의 대체적 대변인이 되는 것이다.

다른 예: <p> <img src="house.png" height="110" width="320" alt="이 집은 초록색 창문이 있는 흰색 집이다." title="서쪽에서 바라보는 집" /> 이 집은 XXXXX 중간에 위치하고 있다. </p>

이고 이하는 아니다.

<p> <img src="house.png" height="110" width="320" alt="초록색 창문의 흰 집." title="서쪽에서 바라보는 집" /> 이 집은 XXXXX 중간에 위치하고 있다. </p>

이것은 참 중요한 구별이며 웹이 아직도 WYSIWYG(보이는 그대로가 결과물인것) 이라고 생각하는 제작자들에게는 설명하기 어려운 부분이다.

올바른 첫번째 html 예제 부분을 보며 이미지가 꺼져있다면 어떻게 렌더링 되고 싶은지 상상해 보라. 아마도 이하와 같을 것이다.

이 집은 초록색 창문이 있는 흰색 집이다. 이 집은 xxxx 중간에 위치하고 있다.

그리고 이하와 같지는 않을것이다.

+-------------------------------------------+ | 이 집은 초록색 창문이 있는 흰색 집이다. | +-------------------------------------------+ 이 집은 xxxx 중간에 위치하고 있다.

문단의 한 부분처럼 렌더된것은 "대체 텍스트 인라인 렌러딩" 이라고 하고 틀 안에 들어간 것은 "placeholder box 틀 안의 렌더링된 대체 텍스트" 라고 부른다.

주장 #4

"생각컨데 위의 이미지는 방향을 나타내고 있는데 유저의 이해를 위하여 각각(텍스트와 이미지)의 역할이 있으며 어느 한 부분도 때어 놓을수 없는거 같다."

아니다. 이미지가 없다면 바른 인라인 대체 텍스트가 이미지의 title보다 그렇다 아니할지라도 빈 박스 보다 낫다. 그리고 빈 박스는 못생겼다.

주장 #5

"만약 이 예제에서 이미지가 읽히는데 실패하면서 사이즈가 지정된 이미지 대신 대체 텍스트가 출력되었다면 시멘틱 아이덴디티를 지키면서 유저들에게 페이지가 제대로 표현될만큼 로딩되지 않았다는 팁을 줄수 있다고 본다. 만약 대체 텍스트가 인라인으로 문단안에 위치하여 보이게 되면 (페이지가 제대로 로딩된 것인지 아닌지) 유저들에게 혼란을 줄수 있는거 같다."

유저들은 제작자가 실수를 한것인지 아닌지에 관심을 두는 것이 아니다. 유저들은 정보를 원한다. 이미지가 제공되지 않았다면 페이지가 상황에 맞추어 적응해야 한다. 그리고 그것이 바로 대체텍스트 alt 가 하는 일이다.

주장 #6

"spacer GIF (레이아웃을 위해 사용되는 텅빈 gif) 를 사용하는 페이지가 있다. 하지만 웹마스터의 에러로 인해 존재하지 않는 파일이름으로 지정되어 이미지가 출력되지 않고 파일이름이 출력되며 그것이 레이아웃을 깨고 있다."

그럼 제대로된 spacer GIF 파일이름으로 바꾸면 되지 않는가. 페이지에 문제가 있다면 당연히 수정되어야 한다. 그리고 레이아웃을 위한 것들은 CSS 가 사용되어야 하겠다.

주장 #7

"하지만 왜 파일명이 출력되는가? "alt" 텍스트가 없다면 파일이름이 아니라 아무것도 출력하지 않아야 하는거 아닌가?"

HTML 스펙 에 따르면 파일 이름을 써야 한다.

주장 #8

"대체 텍스트를 넣었다고 가정하고 (title이나 name 혹은 파일이름이 없다면) 사이즈가 정해진 박스안에 대체 텍스트를 보여준다면 1)언제나 대체텍스트는 보여지고 (텍스트가 다 보여지도록 툴팁을 더하고) 2)특정 상황을 염려하지 않아도 되고 3)페이지 레이아웃을 깨지 않아도 된다."

이건 기초를 놓친 것이다. HTML 은 "페이지 레이아웃"을 위한것이 아니다. 만약 제작자가 원하는대로 표현되지 않았다면 어쩔수 없다. 그게 표현된것이다. 예를들어 폰트가 바꼈다거나 유저 스타일시트가 적용됬다거나 제작자의 색상들이 disable 되었다거나 브라우저가 그래픽을 지원하지 않는 경우, 페이지가 방화벽을 지나가며 필터되었거나 혹은 기타 다른 가능성들이 있다는 것이다.

만약 꾸밈을 위한 그래픽 요소라면 무시해 버릴수 있다 (alt="" 를 해버려야 하는 상황이다) 하지만 decorative 꾸밈을 위한 이미지를 올바른 방향으로 이끌어 줘야하겠다. 만약 꾸밈을 위한 이미지가 아니고 정보적인 요소를 담고 있다면 텍스트와 동일한 폼의 대체 텍스트를 담고 있어야 하며 그것이 우리가 보여주어야 하는 것이다. (혹은 종합적 버전인 filename 이나 title).

위에서 언급했지만 페이지의 중요 요소는 레이아웃이 아니라 컨텐츠다. 만약 이미지를 disable 했는데 페이지가 레이아웃을 위한 이미지들에 의지하고 있었다면 어쩔수 없다. 괜찮다. 레이아웃보다 나머지 텍스트에 집중하면 된다.

주장 #9

"ALT 는 접근성의 이슈이다. 목표는 중요 포멧(여기서는 이미지)이 보이지 않는 컨텐츠에도 접근토록 하는 것이다."

꼭 그렇지 만은 않다. 목표는 "의도한" 컨텐츠에도 접근토록 하는 것이다.

주장 #10

"대체 텍스트가 이미지의 의미적 대체 방법이라는 강조는 인터페이스의 툴로써 상당수 사용되는 이미지들을 빼놓고 있다. (anchor link 나 이미지맵)"

그러한 사용들을 배재하려는 것이 아니다. 버튼에 "Submit"(확인)이라고 적힌 이미지가 갖는 "의미"가 무엇이라고 생각하는가? 의미는 확인(제출) 이다. 고로 대체 텍스트는 Submit 인 것이다. 반복되는 "submit" 임을 감안하고 보통 쓰이는 이미지처럼 alt를 갖는 것이다. (일몰: 이에대해서는 약간 애매한 주장이 나올수 있습니다. 한국에서는 제출이라는 단어를 포함한 버튼이 없죠. 보통 '확인' 이라는 단어를 쓰니 의미적인 반대 의견을 낼수 있지만 아무튼 나중에 다루기로 합니다.)

주장 #11

"나는 꾸밈 이미지의 대체 텍스트가 "컨텐츠 안의 이미지 목적을 위한 기능적 텍스트모드 대체" 라는 기본원칙을 표현한다는 쪽으로 기울고 있다." (주석: 대체 텍스트는 단순히 텍스트 모드를 위한 기능적 대체 방법 이지 않는가 라는 의문)

동의하지 않는다. 꾸미는 이미지의 목적으로써 기능적 텍스트 모드 대체는 ASCII 의 부속물이겠지만 그것은 alt 텍스트라고 하기엔 부적절하다. 대체 텍스트는 텍스트 미디어 뿐만이 아니라 Speech 말하는 미디어 에도 사용된다. 그러므로 여기서 텍스트 대체 방법은 텍스트 모드의 대체 방법이 아닌 것이다.

결론

이미지를 갖고 있는 페이지를 Lynx 가 어찌 하는지 본적이 있는가? 제작자가 제대로 대체 텍스트를 사용하였다면 유저들은 Lynx 라 하더래도 모든 정보를 얻는다. 물론 이미지가 보일때 보다 약간 효율이 떨어질수도 있다. 하지만 유저들에게 "아 죄송합니다. 이미지를 보셔야만 저의 정보가 제값을 합니다." 라고 아무도 말해주지 않았다.

이상 Ian Hicks의 글이었습니다. 이번글은 의미적인 논란이기에 이해와 해석에 상당한 어려움이 있었습니다. 하지만 그만큼 다룰만한 글이라고 생각됩니다. 위에서 잠깐 언급한 "확인" 버튼에 대하여는 사용성과 관련하여 후에 다루도록 하겠습니다.