Достъпност на имейлите: инклузивен HTML

За повечето организации имейлът е най-честата точка на контакт, която имат с клиентите. Потвърждение на поръчка, нулиране на парола, месечно извлечение, бюлетин — тези съобщения често пристигат много преди някой да посети уебсайта ви и пристигат много по-често. И все пак достъпността на имейлите е един от най-пренебрегваните ъгли на дигиталното приобщаване. Екипи, които влагат много в достъпен уебсайт, рутинно изпращат кампании, изградени върху объркан маркъп, съдържание само от изображения и бутони, които екранен четец прочита като „щракнете тук”.

Причината е отчасти историческа и отчасти техническа: HTML имейлът е отделна дисциплина със свои ограничения, свои механизми за рендиране и свои режими на отказ. Техники, които са втора природа в съвременния уеб — семантични ориентири, flexbox оформления, потребителски свойства на CSS — са ненадеждни или направо неработещи в матрицата на имейл клиентите. Да направиш имейл достъпен не е същата работа като да направиш уеб страница достъпна и да ги третираш като еднакви е точно причината толкова много имейли да се провалят.

Това ръководство преминава през това, което достъпността на имейлите реално изисква: как да структурираш маркъпа, така че помощните технологии да могат да го анализират, как да обработваш презентационните таблици, които все още стоят в основата на имейл оформлението, как да пишеш алтернативен текст и връзки, които имат смисъл извън контекста, как да оцелееш в тъмен режим и при увеличение и как да тестваш резултата в Outlook, Gmail, Apple Mail и екранни четци. Ако предпочитате специалисти да направят това за вашите шаблони, нашата услуга за ремедиация на имейли покрива целия стек.

Защо HTML имейлът е отделна дисциплина

Уеб страницата се рендира в браузър. Има шепа масови браузъри, те се обновяват по предвидими графици и се сближават с уеб стандартите. Имейлът е обратното. Вашето съобщение може да бъде отворено в десетки клиенти — Outlook в Windows, Outlook в уеб, новият Outlook, Gmail в браузър, приложението Gmail, Apple Mail в macOS и iOS, Yahoo, Samsung Email и много други — всеки с различен механизъм за рендиране и различно, често смаляващо се подмножество от поддържан HTML и CSS.

Най-известният пример е настолният Outlook в Windows, който исторически рендираше имейли, използвайки механизма на Microsoft Word, а не истински браузърен механизъм. Само това принуждава разработчиците на имейли да се връщат към таблични оформления, вградени стилове и защитни модели, които уебът изостави преди години. Много клиенти също премахват <style> блокове, отказват модерен CSS и пренаписват атрибути, които смятат за несигурни.

За достъпността това е изключително важно. Семантичният HTML, на който разчитате за уебсайт — <nav>, <main>, ARIA ориентири — често се премахва или игнорира в имейла. Не можете да се облягате на една-единствена цел за рендиране. Затова достъпността на имейлите се състои в изграждането на съобщения, които деградират плавно: които остават четими, навигируеми и смислени дори когато оформлението се срутва, изображенията не се зареждат или стиловете се изхвърлят. Този защитен начин на мислене е основата, върху която се изгражда всичко останало в това ръководство, и е причината имейлът да принадлежи към специална програма за услуги по достъпност, вместо да бъде включен в общата уеб работа.

Семантична структура и логичен ред на четене

Дори при всички ограничения, най-ценното, което можете да направите за потребител на екранен четец, е да дадете на имейла ясна, линейна структура. Екранните четци четат съдържанието в реда на DOM, така че редът на вашия маркъп е редът, в който се чува вашето съобщение. Ако дизайнът ви поставя рекламен банер преди самото съобщение, банерът се обявява първи — независимо как изглежда оформлението.

Използвайте истински елементи на заглавия, за да установите йерархия. Имейлът трябва да има едно логично заглавие от най-високо ниво (обикновено основната тема или оферта) като <h1>, като следващите секции се маркират като <h2> и <h3>. Потребителите на екранни четци навигират по заглавия, за да преглеждат съобщение, така че добре структуриран план превръща стена от текст в нещо за бързо преглеждане. Не имитирайте заглавия с голям, удебелен <span> текст; визуално може да изглежда като заглавие, но помощните технологии чуват обикновен основен текст. По същия начин използвайте истински маркъп за списъци (<ul>, <ol>, <li>) за списъци и задайте езика на документа с атрибут lang върху елемента <html>, за да използват екранните четци правилното произношение и глас.

Редът на четене също трябва да има смисъл сам по себе си. Прочетете маркъпа си отгоре надолу, пренебрегвайки всякакво стилизиране, и се запитайте дали все още разказва свързана история. Ако да, имате солидна основа. Ако значението зависи от визуалното подреждане, имате работа за вършене — и тази работа обикновено започва с таблиците за оформление.

Презентационни таблици и role=“presentation”

Имейл оформлението се изгражда с таблици. Това не е стилистичен избор; това е изискване за оцеляване, защото табличното оформление е единственият подход, който се рендира последователно в матрицата на клиентите. Проблемът е, че таблиците носят семантично значение. По подразбиране екранният четец обявява <table> като таблица с данни, прочита броя на редовете и колоните и се опитва да свърже клетките със заглавия. За таблица, която съществува единствено за да позиционира лого до заглавие, това обявяване е шум — а в рамките на вложен имейл с множество таблици се превръща в изтощително, дезориентиращо изживяване.

Решението е да кажете на помощните технологии, че тези таблици са скеле за оформление, а не данни. Добавете role="presentation" към всяка таблица, използвана за оформление: <table role="presentation">. Това премахва семантиката на таблицата, така че екранните четци да пропускат обявленията за редове и колони и просто да четат съдържанието вътре по ред. Това е една от най-важните и най-често пропускани техники в достъпността на имейлите и трябва да се прилага към всяка таблица за оформление, включително вложените, а не само към най-външната обвивка.

Няколко свързани практики подсилват това. Не добавяйте summary, заглавни клетки <th>, scope или <caption> към презентационните таблици — това е маркъп, носещ значение, запазен за истинските таблици с данни. Ако имейлът ви съдържа реални таблични данни, като подробна разписка, направете обратното: оставете я като таблица с данни с правилни <th> заглавия и атрибути scope, така че връзките да се предават. Принципът е последователност между външния вид и семантиката. Постигането на това в библиотека от шаблони е придирчиво и лесно за връщане назад, поради което е основна част от нашата работа по ремедиация на имейли.

Изображения и алтернативен текст

Изображенията носят голяма тежест в имейла и много получатели ги виждат с деактивирани изображения по подразбиране — някои клиенти блокират отдалечените изображения, докато потребителят не се съгласи. Това прави алтернативния текст двойно по-важен: той е едновременно изискване за достъпност и резервният вариант, който поддържа съобщението ви разбираемо, когато изображенията не се зареждат.

Всеки елемент <img> се нуждае от атрибут alt. Какво влиза вътре зависи от целта на изображението. За информативно изображение — продуктова снимка, инфографика, диаграма — алтернативният текст трябва да предава същата информация, която предоставя изображението. „Синя обувка за бягане, страничен изглед” е по-полезно от „image1.png”, а алтернативният текст на диаграма трябва да обобщава извода, а не само да я обозначава като диаграма. За текст, изобразен като изображение, което все още се случва с рекламни заглавия, алтернативният текст трябва да възпроизвежда думите точно, защото иначе това съдържание е невидимо за екранните четци и за всеки с изключени изображения.

За декоративни изображения — разделители, фонови орнаменти, разделителни линии, които не добавят нищо към значението — използвайте празен alt атрибут, записан като alt="". Това изрично казва на екранните четци да пропуснат изображението, вместо да обявяват име на файл. Пълното пропускане на атрибута не е същото нещо; липсващ alt често кара екранните четци да прочитат URL адреса на изображението, което е най-лошото от двата свята. Бъдете особено внимателни с честия модел на използване на изображение като бутон или връзка: алтернативният текст на това изображение трябва да описва действието, например „Завършете покупката си”, а не картината.

Още един специфичен за имейла момент: никога не поставяйте съществена информация само в изображение. Код за купон, номер за потвърждение, връзка за отписване, основният призив за действие — ако някое от тях съществува само като пиксели, то изчезва за потребителите с изключени изображения и екранни четци. Запазете критичното съдържание като жив, избираем текст.

Контраст и тъмен режим

Текстът трябва да е четим, което означава, че трябва да отговаря на изискванията за контраст. WCAG 2.2 изисква съотношение на контраст от поне 4,5:1 за нормален текст и 3:1 за едър текст спрямо неговия фон. Светлосив текст върху бял фон — вечен фаворит на минималистичния имейл дизайн — често се проваля, както и бледи бутони и цветове на връзки с нисък контраст. Тези прагове важат за имейла точно както за уеба и същите критерии за успех на WCAG 2.2 са еталонът; нашият по-широк преглед на съответствие с WCAG обяснява как тези критерии се съчетават.

Имейлът добавя усложнение, което уебът в по-голямата си част няма: тъмният режим. Много клиенти — сред тях Apple Mail, Outlook и Gmail — автоматично трансформират имейлите, когато потребителят е активирал тъмен режим. Някои просто сменят фона; други агресивно инвертират или преоцветяват палитрата ви, понякога частично. Резултатът е, че бутон с тъмен текст върху светъл марков цвят може да се окаже с тъмен текст върху тъмен инвертиран фон, свеждайки контраста до нищо. Черен текст в цветна кутия може да стане невидим. Лога с прозрачен фон могат да изчезнат на тъмно платно.

Няма универсален контрол върху тъмния режим и съществуващите техники се различават в зависимост от клиента, но защитните принципи са стабилни. Проектирайте с мисъл за двата режима. Избягвайте чисто черно или чисто бяло като базови цветове, тъй като те не оставят място на клиента за коригиране. Дайте на логата и ключовите графики контрастен контур или плътна фонова плоча, за да оцелеят при инверсия. Тествайте действителния рендиран резултат в тъмен режим във всеки голям клиент, вместо да се доверявате, че дизайнът ви за светъл режим ще се пренесе. Целта е текстът и интерактивните елементи да остават над прага на контраст, независимо как клиентът ги обръща.

Описателни връзки и достъпни бутони

Потребителите на екранни четци често извикват списък с всички връзки в съобщение, за да навигират или да решат накъде да отидат. В този списък текстът на връзката се появява лишен от заобикалящия го контекст. Съобщение, пълно с „Щракнете тук”, „Прочетете повече” и „Научете повече”, произвежда безполезен опис от идентични, безсмислени записи. Текстът на всяка връзка трябва да има смисъл сам по себе си: „Прочетете нашия пролетен доклад за устойчивостта” или „Проследете поръчката си” казва на потребителя точно накъде води връзката без никакво заобикалящо изречение.

Същото важи за бутоните, които в имейла обикновено са връзки, стилизирани да изглеждат като бутони — често изградени с техниката на „бронирания бутон”, използваща вложени таблици и фонови цветове, за да се рендират в различни клиенти. Каквато и да е конструкцията, достъпното име на бутона трябва да описва неговото действие. Празен или неясен бутон, или такъв, чийто текст живее само във фоново изображение, е задънена улица за помощните технологии. Ако бутонът е базиран на изображение, действието принадлежи на алтернативния текст на изображението.

Направете целите на връзките и бутоните достатъчно големи, за да се докосват удобно — WCAG 2.2 въведе минимален размер на целта, а на мобилно устройство твърде малка цел за докосване дразни всички, не само потребителите с двигателни увреждания. Уверете се, че връзките са различими по нещо повече от цвят, тъй като връзките само с цвят се провалят за потребители със слабо зрение или цветна слепота; подчертаването е най-сигурната подсказка. И дайте на всяка връзка реална, работеща дестинация вместо заместител. Неясният текст на връзки е един от най-честите провали, които виждаме, и се появява и в уеба, не само в имейла — нашият обзор на чести проблеми с достъпността, които да избягвате покрива същия модел в по-широк контекст.

Прехедърът и изживяването при преглед

Прехедърът — понякога наричан текст за преглед — е откъсът текст, който се появява до или под темата във входящата кутия, преди съобщението да бъде отворено. Много имейли го пропиляват, оставяйки го по подразбиране да приема какъвто текст се случи да дойде първи: ред „Имейлът не се показва правилно?”, връзка „отписване” или низ от празен алтернативен текст. За потребителите на екранни четци, навигиращи входящата си кутия, и за всеки, който решава дали да отвори, този пропилян прехедър е изпуснат шанс за комуникация.

Напишете обмислен, смислен прехедър, който обобщава целта на имейла, и го поставете като първото текстово съдържание в тялото, за да е това, което входящата кутия улавя. Стандартната техника е скрит блок текст близо до началото на имейла, стилизиран да бъде визуално скрит, но все пак достъпен за клиентите и помощните технологии. Бъдете внимателни как го скривате: лошо скрит прехедър може или да се покаже като нежелан видим ред, или да бъде напълно пропуснат от екранните четци. Допълнете го по подходящ начин, така че последващо съдържание от входящата кутия да не пропуска съседен текст в прегледа.

Третирайте прехедъра като част от информационната архитектура на съобщението. Комбиниран с ясна тема и силно начално заглавие, той дава на всеки получател — виждащ или не — бързо, точно усещане какво е имейлът и защо има значение.

Адаптивно оформление и увеличение

Имейлите се четат на телефони толкова, колкото и на настолни компютри, и се четат от хора, които увеличават, за да уголемят текста. И двете изискват оформлението да се адаптира. Фиксирано, широко оформление, което принуждава хоризонтално превъртане на малък екран или което се чупи, когато потребител увеличи размера на текста, е бариера — а WCAG 2.2 има критерии както за пренареждане, така и за разстояние между текста, които важат тук.

Изграждайте имейлите да бъдат адаптивни: оформление с една колона на тесни екрани почти винаги е най-надеждният и достъпен избор, защото запазва реда на четене и избягва съдържание едно до друго, което се срутва непредсказуемо. Където използвате media заявки за смяна на оформления, помнете, че някои клиенти ги игнорират, така че рендирането по подразбиране трябва все пак да е използваемо. Задайте размери на шрифта достатъчно големи, за да се четат без увеличение — основен текст под около 14 до 16 пиксела е труден за много хора на мобилно устройство — и избягвайте да фиксирате височината на реда или разстоянието между буквите толкова стегнато, че уголеменият текст да се припокрива или да се отрязва.

Тествайте какво се случва, когато потребител увеличи или повиши системния размер на шрифта на устройството си. Съдържанието трябва да се пренареди и да остане четимо, вместо да прелива от контейнера си или да изчезва зад други елементи. Наградата е имейл, който работи не само за потребители със слабо зрение, но за всеки, който чете на малък екран при несъвършени условия.

Тестване в различни клиенти и екранни четци

Не можете да проверите достъпността на имейла, като инспектирате само кода, защото цялото предизвикателство е, че клиентите рендират един и същ код различно. Тестването трябва да се случва в представителна матрица от клиенти и помощни технологии, при условията, които използват реалните получатели.

Покрийте поне основните клиенти: Outlook (настолен в Windows, плюс уеб и новите версии), Gmail (уеб и мобилното приложение) и Apple Mail (macOS и iOS). За всеки проверете рендирането както в светъл, така и в тъмен режим, с включени и изключени изображения и при увеличено увеличение. След това наслоете екранните четци отгоре — VoiceOver с Apple Mail в macOS и iOS, NVDA или JAWS с Outlook и Gmail в Windows и TalkBack с приложението Gmail в Android. Слушайте имейла така, както би го направил потребител на екранен четец: обявяват ли се заглавията, логичен ли е редът на четене, мълчат ли таблиците за оформление, имат ли смисъл връзките в списъка с връзки, обявяват ли изображенията полезен алтернативен текст или остават тихи, когато са декоративни?

Автоматизираните проверки имат своето място — те могат бързо да отбележат липсващи alt атрибути, нисък контраст и липсващи езикови атрибути в много шаблони — но не могат да преценят дали алтернативният текст е смислен, дали редът на четене разказва правилната история или дали името на бутон описва неговото действие. Тази преценка изисква ръчно тестване, в идеалния случай включващо тестване от хора, които използват помощни технологии всеки ден. Нашето ръководство за ръчни одити на достъпност обяснява защо човешкото тестване е незаменимо, а нашите одити от хора с увреждания внасят точно тази перспектива на преживян опит в имейла.

Една дума на предупреждение: не се изкушавайте от джаджи за „наслагване” за достъпност, които обещават мигновено съответствие. Те не работят за уебсайтове и са без значение за имейла, където няма страница, в която да се инжектира скрипт. Истинската достъпност на имейлите идва от поправянето на маркъпа, а не от прикачено допълнение.

Ремедиация на шаблони на ниво ESP

Поправянето на един имейл е полезно. Поправянето на източника, който генерира всеки имейл, е преобразяващо. Повечето организации изпращат чрез доставчик на имейл услуги — Mailchimp, Klaviyo, Salesforce Marketing Cloud, Braze и подобни — където кампаниите се сглобяват от главни шаблони, многократно използваеми модули и блокове съдържание с плъзгане и пускане. Ако тези базови шаблони носят поправките за достъпност, всяко бъдещо изпращане ги наследява автоматично и маркетинговият екип не трябва да помни контролен списък за всяка кампания.

Това е най-рентабилното място за инвестиране. Ремедирайте главния шаблон, така че таблиците за оформление да носят role="presentation", езиковият атрибут да е зададен, структурата на прехедъра да е налице и скелето на заглавията да е правилно. Ремедирайте всеки многократно използваем модул — hero блока, картата за статия, бутона, долния колонтитул — така че каквото и да плъзне екипът, да е достъпно по конструкция. Установете модели за алтернативен текст, така че редакторите да бъдат подканвани да го пишат, и вградете цветове с безопасен контраст и съобразени с тъмния режим в марковата палитра, която шаблоните използват.

Уловката е, че конструкторите с плъзгане и пускане могат също да върнат назад достъпността: конструктор може да премахне role="presentation", да осакати маркъпа при експортиране или да позволи на редактор да постави недостъпен блок. Така че ремедиацията на шаблони трябва да бъде съчетана с управление — насоки, стъпки за преглед и периодично повторно тестване, докато ESP и неговото поведение при експортиране се променят. Тук се изплаща вграждането на достъпност в работния процес; нашата услуга за подобряване на процесите по достъпност помага на екипите да направят достъпния имейл норма, а не последваща мисъл, а консултиране по достъпност го привежда в съответствие с по-широката ви програма за съответствие. За организации, обхванати от Европейския акт за достъпност, достъпните комуникации с клиенти са част от картината, което нашият преглед на съответствие с EAA излага.

QualiBooth комбинира софтуер за сканиране на достъпност за проблемите, които машините улавят надеждно, с експертна ръчна ремедиация за преценките, които те не могат да направят — за уебсайтове, документи и имейли еднакво. Ако вашите имейли са част от това как обслужвате клиентите, те заслужават същата прецизност като останалата част от вашето дигитално имущество.

Заключение

Достъпността на имейлите не е по-малка версия на уеб достъпността — тя е свързана, но отделна дисциплина, оформена от фрагментиран пейзаж от клиенти, таблични оформления и механизми за рендиране, които пренебрегват голяма част от съвременния уеб. Добрата новина е, че техниките са добре установени: семантична структура и стабилен план на заглавия, role="presentation" на всяка таблица за оформление, смислен алтернативен текст с празен alt за декорация, контраст, който оцелява в тъмен режим, връзки и бутони, които се описват сами, обмислен прехедър, адаптивни оформления, които издържат на увеличение, и дисциплинирано тестване в различни клиенти и екранни четци. Приложете ги на ниво шаблон и достъпността спира да бъде задача за всяка кампания и се превръща в свойство на вашата система.

Възвръщаемостта е реална. Достъпните имейли достигат до повече хора, четат се ясно с изключени изображения и обикновено се представят по-добре, защото яснотата и стабилността помагат на всички. Ако искате помощ, нашата услуга за ремедиация на имейли може да одитира вашите шаблони, да ги поправи на ниво ESP и да провери резултата в цялата матрица от клиенти — и можете да заявите демонстрация или да стартирате безплатно сканиране на вашия уебсайт, за да видите къде се намира останалата част от вашето дигитално имущество.

Често задавани въпроси

Наистина ли ми трябва role="presentation" на всяка таблица за оформление? Да. Без него екранните четци обявяват всяка таблица за оформление като таблица с данни, прочитайки броя на редовете и колоните и нарушавайки потока. Тъй като имейл оформленията влагат таблици, атрибутът трябва да е на всяка таблица за оформление, а не само на външната обвивка. Истинските таблици с данни, като разписките, вместо това запазват своята семантика на данни.

Какво да поставя в алтернативния текст за декоративно изображение? Използвайте празен alt атрибут, записан alt="", така че екранните четци да пропуснат изображението. Не пропускайте атрибута напълно, защото липсващ alt често кара името на файла или URL адреса на изображението да бъде прочетено на глас.

Как да спра тъмния режим да не разваля имейла ми? Не можете напълно да контролирате как всеки клиент обработва тъмния режим, но можете да проектирате защитно: избягвайте чисто черно и бяло, дайте на логата контрастен фон или контур, поддържайте контраста над праговете на WCAG 2.2 и тествайте рендирания резултат в тъмен режим във всеки голям клиент, вместо да приемате, че дизайнът ви за светъл режим ще се пренесе.

Може ли автоматизиран инструмент да направи имейла ми достъпен? Автоматизираните инструменти улавят някои проблеми — липсващи alt атрибути, нисък контраст, липсващи езикови настройки — но не могат да преценят дали алтернативният текст е смислен, дали редът на четене има смисъл или дали връзките и бутоните описват предназначението си. Това изисква ръчно тестване с екранни четци. Джаджите за наслагване за достъпност не са решение и не са приложими за имейла.

По-добре ли е да се поправят отделни имейли или шаблони? Шаблони. Ремедирането на главни шаблони и многократно използваеми модули във вашия ESP означава, че всяко бъдещо изпращане наследява поправките, което е далеч по-рентабилно от поправянето на кампании една по една. Съчетайте го с управление, така че конструкторите с плъзгане и пускане да не въвеждат повторно проблеми.