접근성 및 모바일 환경을 위한 메일 작성가이드라인(광고메일, DM 등)

1. 메일 클라이언트는 사용자마다 다릅니다.

Naver 웹메일, Outlook
2007, Gmail, iPhone 메일함… 다종 다양한 환경에서 이용자들은 메일을 봅니다. 메일 클라이언트들은 벤더에 따라 다르며, 또한 버전 및 사용자의
환경설정에 따라 또 달라집니다. 따라서 특정 메일 클라이언트에서는 문제없는 메일이라 하더라도 다른 메일
클라이언트를 사용하는 사용자에게는 문제가 될 수 있습니다.

2. CSS 지원여부

메일 클라이언트가 HTML을 지원하는 것은 필수가 아닙니다. 따라서 메일 클라이언트마다 다 다른 형태로 HTML 렌더링을 지원합니다. 예를 들어 Outlook 2007은 Internet Explorer에 탑재된 렌더링엔진대신, MS-Word
2007에 들어있는 렌더링엔진을 사용합니다. 그러나
Outlook 2003은 IE 6 렌더링엔진을 이용합니다.
따라서 HTML 태그가 똑 같은 모양으로 렌더링될 거라는 보장이 없습니다.

2-1. <style> & <link>

현재 유통되고 있는 메일 클라이언트 (웹메일 포함)의 일부는 Style 태그나
link 태그를 사용할 수 없는 경우들이 있습니다. 따라서 외부 CSS 혹은 내부 CSS 사용이 될 거라는 보장이 없습니다.

2-2. CSS Selectors

선택적 CSS 셀렉터가 안되는 경우들이 많습니다. (어차피 style, link 태그를 못쓰는 경우들을 고려한다면
불필요한 이야기)

2-3. 문제가 있을 수 있는 CSS
속성들

background-color, background-image,
background-position, background-repeat, border, border-collapse,
border-spacing, bottom, caption-side, clip, cursor, clear, direction, display,
empty-cells, float, font-family, font-variant, height, left, letter-spacing,
line-height, list-style-image, list-style-position, list-style-type, margin,
opacity, overflow, padding,  position,
right, table-layout, text-indent, text-transform, top,vertical-align,  visibility, white-space, width, word-spacing,
z-index…

사실 엄밀히 말하자면 모든 CSS에 다 문제가 있을 수 있습니다. 이메일은 HTML문서가 아니기 때문에 정상적으로 렌더링될거라는 보장을
하면 안됩니다.

Inline-css (HTML의
style attribute를 이용)의 경우는 상대적으로 잘 지원되지만, 이 경우에도 단축형은 지원하지 않는 케이스들이 있습니다.

결론 : inline-css를 제외하고는 CSS 사용에 문제있음. 가능하면
CSS를 이용하여 디자인하지 말 것. Inline-css 에서도 모든 속성이 제대로 지원될
거라는 보장없음.

3. 폭과 정렬

일부 메일 클라이언트의 경우, 표시되는 메일 본문의 폭이 매우 좁을
수도 있습니다. 특히 모바일 환경에서 볼 경우에는 메일 클라이언트에 따라 그 폭이 200pixel 미만일 수도 있습니다.

또, 대부분의 메일 클라이언트는 가운데 정렬이 지원되지 않을 수 있으며, 시도할 경우 레이아웃이 매우 이상하게 바뀔 수 있습니다. 좌측정렬을
기본으로 삼아야 합니다.

결론 : 장폭의 이미지, 긴 URL의 링크 등을 그대로 제공하지 말 것.

4. table 태그의 이용

Table이 반드시 지원될 거라는 보장은 없지만, 그나마 레이아웃을 잡기 위해서는 table 태그를 사용할 수 밖에
없습니다.

HTML 4.0 기준의 Table 관련
태그들은 제법 다양한 메일 클라이언트에서 지원되며, css property를 사용함에 제한이 있으므로 table이나 td 태그의 html
attribute (border, valign, align, cellspacing, cellpadding 등)을 이용하면 레이아웃을 잡을 수 있습니다. 그러나 colspan이나 중첩 테이블 등의 경우 제대로 표시된다는 보장이 없습니다. 100%
보장되는 것은 아니므로 가능한 다단 편집대신 1단으로 컨텐트를 구성하는 쪽이 바람직합니다.

혹시 table 관련 태그를 사용할 경우, width를 지정하겠다면 가능한 한 픽셀단위 고정폭을 사용하지 말고, %단위의
가변폭을 사용하는 쪽이 바람직합니다.(사용자 환경을 알 수 없으므로 렌더링될  넓이를 정확히 추측할 수 없기 때문.) 또한
가장 바깥쪽 넓이를 100%로 잡을 경우 몇몇 웹메일 클라이언트에서는 제대로 렌더링되지 않는 문제가
발생할 수도 있으므로 주의해야 합니다. (그러나 반대로, 몇몇
메일 클라이언트에서는 %단위를 사용하는 것 자체가 문제가 될 수도 있음. 어쩌란 말이냐… -_-a)

5. 각종 embed 요소

심지어는 img 태그마저도 제대로 안 걸릴 수 있습니다. 나아가 플래시 등을 로딩하기 위한 embed 태그나 javascript 등은 사용하지 마세요. (특히, 버튼이나 링크등을 javascript로 작성하지 말 것!)

결론 : embed, javascript.. 이런 거 전부 쓰지 말
것.

6. background image

백그라운드 이미지는, 없어도 되는 이미지가 백그라운드 이미지입니다.

1) 전달해야할 텍스트 컨텐트가 없는 이미지라면 백그라운드 이미지입니다.

2) 전달해야할 텍스트 컨텐트가 포함된 이미지라면 img 태그를 사용하세요.

3) 백그라운드 이미지는 table
td 태그의 background-image attribute를 이용하여 표시할 수 있지만, 이 경우에도 제대로 표시될 거라 확신할 수 없습니다. 따라서 백그라운드
이미지는 “없어도 메시지 전달에 지장없는” 이미지여야 합니다.

7. image

<img> 태그는 제법 잘 쓸 수 있습니다. 주의할 점은, sliced image를 남발하지 마세요. 제대로 된 위치에 출력되리라는 보장이 없습니다. 꼭 복잡한 이미지를
써야겠다면 table 태그를 이용하여 레이아웃을 잡고, 가능한한
백그라운드 이미지로 통이미지를 쓰는 쪽이 더 나을 수 있습니다. 단,
이렇게 잡은 이미지와 레이아웃이 반드시 생각대로 표시된다는 보장이 없으므로 중요한 핵심메시지를
img 태그 혹은 백그라운드 이미지로 넣으면 안됩니다.

이미지가 표시되지 않는 경우, 해당 이미지가 전달하려던 메시지가 안보이게
되므로 반드시 alt 속성을 이용해서 대체텍스트를 제공해야 합니다. 또, width,height 속성을 정확히 사용해서 이미지가 표시되지 않더라도 해당 영역을 확보함으로써 레이아웃이
깨지지 않도록 처리해줘야 합니다.

결론 : 브라우저의 이미지 표시 옵션을 끄고서도 메일의 내용이 이해될
수 있도록 해야 함.

8. 사용해서 안전한 HTML 요소

결론은 없습니다. Plain Text를 제외한 모든 HTML 요소들의 이용을 보장할 수 없습니다. 그러나 통계상 다음 HTML 요소들의 순서대로 제법 많은 메일 클라이언트에서 지원되므로 최소한으로 사용은 가능합니다.

–     
<a> : 그러나 hyper-text 링크가 표시안되는 경우가 있으므로 사용자가 복사해서 이용할 수 있는 대체 URL 문자열을 같이 출력시켜주는 쪽이 좋습니다. 또한, 가능한한, 링크의 오픈 타겟은 target=”_blank”를
사용해서 새 창에서 열리도록 하는 것이 좋습니다. 그렇지 않은 경우 일부 웹메일 사용자에게는 매우 불쾌한
경험이 될 수 있습니다.

또한, 문서내 anchor가 먹지 않는 경우가 있으니 #을 이용한 anchor 사용은 자제해야합니다.

–     
<img> : 일부 속성이 적용되지
않을 수 있습니다. 이미지 자체의 출력이 안되는 경우도 있습니다. 특히
모바일 환경의 메일 클라이언트에서는 네트웍사용량을 줄이기 위해 img를 선택적으로 로딩하는 경우도 있습니다. 이런 경우 등을 대비하기 위해 “alt=” 속성을 이용해서 이미지의
내용을 보여주는 대체텍스트를 작성해야 합니다.

Ex) <img src=”http://somewhere.com/image/order_confirm_message.gif”
alt=”고객님의 주문이 접수되었습니다.”/>

–     
<p>, <div>,
<span>, <a>, <td>, <h1>,<blockquote> : 이런 류의 block/group element 들은 제법 잘 지원되는 편이며, 심지어 style attribute도 일부 지원합니다. 오히려 <font> 태그가 제대로 지원안되는 경우들이 있으니, <p
style=”font-family:Tahoma”> 같은 형태가 더 안전할 수 있습니다.

9. 수신확인은 불가능하다.

RFC3798 등의 규약에서는 메일 헤더에 Receipt 정보를 요구할 수 있게 되어 있으나, 이를 적용하지
않는 메일 클라이언트가 더 많은 현황입니다.

따라서 일부 웹메일에서는 별도로 자체서비스 이용자들간에서만 수신확인을 DB접근
기록등을 토대로 제공하기도 하나 전체 서비스에서는 적용되기 어려운 방법입니다.

한동안 안보이는 작은 이미지 등을 써서 HTTP Request 정보를
이용하여 오픈 여부를 확인하는 방법들을 쓰기도 했었으나 이러한 방법 역시 이미지 출력이 제한되어 있거나,
POP/IMAP 등을 이용하는 사용자에게는 작동하지 않는 경우가 있으므로 별로 신뢰할 수 없으며, 마찬가지
이유로 JavaScript를 이용하는 방법도 사용할 수 없습니다.

결론 : 수신확인을 위해 애쓰지 말 것.

10. 결론

1) 고객에게 반드시
전달되어야 할 모든 메시지는 반드시 텍스트로 만들어져야 합니다.

2) 텍스트 밑에
백그라운드로 이미지를 까는 것은 상관없습니다. (단 CSS로
제어는 안된다고 가정해야 함.)

3) 일부 컨텐트가
반드시 강조되어야 해서 이미지로 메시지를 작성할 경우, alt, width, height를 반드시 작성해야
이미지가 표시되지 않는 환경에서도 사용할 수 있습니다.

4) 모바일 환경에서는
특히 이미지를 표시안하는 경우가 디폴트나 다름없으므로 반드시 주의해야 합니다.

5) script를
절대로 쓰지 마세요.

Reference

http://www.email-standards.org/

http://www.birdhouse.org/etc/evilmail.html

http://www.mailchimp.com/articles/how_to_code_html_emails/

http://mailchimp.blogs.com/blog/2006/01/im_a_web_design.html

http://www.w3.org/TR/1998/NOTE-HTMLThreading-0105

http://msdn.microsoft.com/en-us/library/aa338201.aspx

http://articles.sitepoint.com/article/code-html-email-newsletters

http://www.campaignmonitor.com/templates/

http://www.xavierfrenette.com/articles/css-support-in-webmail/