Sähköpostin saavutettavuusopas HTML-sähköposteille

Useimmille organisaatioille sähköposti on yleisin yhteyspiste asiakkaisiin. Tilausvahvistus, salasanan palautus, kuukausittainen tiliote, uutiskirje — nämä viestit saapuvat usein kauan ennen kuin kukaan vierailee verkkosivustollasi, ja ne saapuvat paljon useammin. Silti sähköpostin saavutettavuus on yksi digitaalisen osallisuuden eniten laiminlyödyistä nurkkauksista. Tiimit, jotka panostavat voimakkaasti saavutettavaan verkkosivustoon, lähettävät rutiininomaisesti kampanjoita, jotka rakentuvat sotkuiselle merkkauskielelle, pelkästään kuviin perustuvalle sisällölle ja painikkeille, jotka kuuluvat ruudunlukijalle muodossa “klikkaa tästä”.

Syy on osittain historiallinen ja osittain tekninen: HTML-sähköposti on oma erikoisalansa, jolla on omat rajoitteensa, omat renderöintimoottorinsa ja omat vikaantumistapansa. Tekniikat, jotka ovat nykyaikaisella verkossa itsestäänselvyyksiä — semanttiset maamerkit, flexbox-asettelut, CSS:n mukautetut ominaisuudet — ovat sähköpostiasiakasohjelmien kirjossa epäluotettavia tai täysin rikki. Sähköpostin tekeminen saavutettavaksi ei ole sama työ kuin verkkosivun tekeminen saavutettavaksi, ja niiden kohteleminen samanlaisina on juuri se syy, miksi niin moni sähköposti epäonnistuu.

Tämä opas käy läpi, mitä sähköpostin saavutettavuus todella vaatii: kuinka jäsentää merkkauskieli niin, että avustava teknologia voi sitä jäsentää, kuinka käsitellä esitystaulukoita, jotka edelleen muodostavat sähköpostin asettelun perustan, kuinka kirjoittaa alt-tekstejä ja linkkejä, jotka ovat ymmärrettäviä asiayhteyden ulkopuolella, kuinka selvitä tummasta tilasta ja zoomauksesta, ja kuinka testata lopputulos Outlookissa, Gmailissa, Apple Mailissa ja ruudunlukijoilla. Jos haluat mieluummin antaa asiantuntijoiden hoitaa tämän mallipohjillesi, sähköpostin korjauspalvelumme kattaa koko pinon.

Miksi HTML-sähköposti on oma erikoisalansa

Verkkosivu renderöityy selaimessa. Valtavirran selaimia on kourallinen, ne päivittyvät ennustettavalla aikataululla ja ne lähentyvät verkkostandardeja. Sähköposti on päinvastainen. Viestisi voidaan avata kymmenissä eri asiakasohjelmissa — Outlook Windowsissa, Outlook verkossa, uusi Outlook, Gmail selaimessa, Gmail-sovellus, Apple Mail macOS:ssä ja iOS:ssä, Yahoo, Samsung Email ja monet muut — joista jokaisella on eri renderöintimoottori ja erilainen, usein kutistuva, osajoukko tuetusta HTML:stä ja CSS:stä.

Pahamaineisin esimerkki on Outlookin työpöytäversio Windowsissa, joka historiallisesti renderöi sähköpostia Microsoft Wordin moottorilla todellisen selainmoottorin sijaan. Jo pelkästään tämä pakottaa sähköpostikehittäjät takaisin taulukkopohjaisiin asetteluihin, sisäänkirjoitettuihin tyyleihin ja puolustaviin malleihin, jotka verkko hylkäsi vuosia sitten. Monet asiakasohjelmat myös poistavat <style>-lohkot, kieltäytyvät nykyaikaisesta CSS:stä ja kirjoittavat uudelleen attribuutteja, joita ne pitävät vaarallisina.

Saavutettavuuden kannalta tällä on valtava merkitys. Semanttinen HTML, johon luotat verkkosivustolla — <nav>, <main>, ARIA-maamerkit — poistetaan tai jätetään huomiotta sähköpostissa toistuvasti. Et voi nojata yhteen renderöintikohteeseen. Sähköpostin saavutettavuus on siksi sellaisten viestien rakentamista, jotka heikkenevät hallitusti: jotka pysyvät luettavina, navigoitavina ja merkityksellisinä, vaikka asettelu romahtaisi, kuvat eivät latautuisi tai tyylit hylättäisiin. Tämä puolustava ajattelutapa on perusta, jolle kaikki muu tässä oppaassa rakentuu, ja siksi sähköposti kuuluu omaan saavutettavuuspalvelut -ohjelmaan sen sijaan, että se taitettaisiin osaksi yleistä verkkotyötä.

Semanttinen rakenne ja looginen lukujärjestys

Kaikista rajoitteista huolimatta arvokkain asia, jonka voit tehdä ruudunlukijan käyttäjälle, on antaa sähköpostille selkeä, lineaarinen rakenne. Ruudunlukijat lukevat sisältöä DOM-järjestyksessä, joten merkkauskielesi järjestys on järjestys, jossa viestisi kuullaan. Jos suunnittelusi sijoittaa mainosbannerin varsinaisen viestin eteen, banneri ilmoitetaan ensin — riippumatta siitä, miltä asettelu näyttää.

Käytä todellisia otsikkoelementtejä hierarkian luomiseen. Sähköpostilla tulisi olla yksi looginen ylätason otsikko (tyypillisesti pääaihe tai tarjous) <h1>-elementtinä, ja sitä seuraavat osiot merkattuna <h2>- ja <h3>-elementeillä. Ruudunlukijan käyttäjät navigoivat otsikoiden mukaan silmäilläkseen viestin, joten hyvin jäsennelty rakenne muuttaa tekstimassan silmäiltäväksi. Älä väärennä otsikoita suurella, lihavoidulla <span>-tekstillä; visuaalisesti se saattaa näyttää otsikolta, mutta avustava teknologia kuulee tavallista leipätekstiä. Käytä samoin aitoa listamerkkausta (<ul>, <ol>, <li>) listoille ja aseta asiakirjan kieli lang-attribuutilla <html>-elementissä, jotta ruudunlukijat käyttävät oikeaa ääntämystä ja ääntä.

Lukujärjestyksen on myös oltava itsessään mielekäs. Lue merkkauskielesi ylhäältä alas jättäen huomiotta kaiken tyylittelyn ja kysy, kertooko se edelleen johdonmukaisen tarinan. Jos kertoo, sinulla on vankka perusta. Jos merkitys riippuu visuaalisesta järjestelystä, sinulla on työtä edessä — ja tämä työ alkaa yleensä asettelutaulukoista.

Esitystaulukot ja role=“presentation”

Sähköpostin asettelu rakennetaan taulukoilla. Tämä ei ole tyylillinen valinta; se on selviytymisvaatimus, koska taulukkopohjainen asettelu on ainoa lähestymistapa, joka renderöityy johdonmukaisesti asiakasohjelmien kirjossa. Ongelma on, että taulukot kantavat semanttista merkitystä. Oletuksena ruudunlukija ilmoittaa <table>-elementin datataulukkona, lukee rivien ja sarakkeiden määrän ja yrittää yhdistää solut otsikoihin. Taulukolle, joka on olemassa puhtaasti sijoittaakseen logon otsikon viereen, tämä ilmoitus on melua — ja sisäkkäisessä, monitaulukkoisessa sähköpostissa siitä tulee uuvuttava, hämmentävä kokemus.

Korjaus on kertoa avustavalle teknologialle, että nämä taulukot ovat asettelutelineitä, eivät dataa. Lisää role="presentation" jokaiseen asetteluun käytettyyn taulukkoon: <table role="presentation">. Tämä poistaa taulukon semantiikan, joten ruudunlukijat ohittavat rivi-/sarakeilmoitukset ja lukevat yksinkertaisesti sisällön järjestyksessä. Se on yksi tärkeimmistä ja useimmin sivuutetuista tekniikoista sähköpostin saavutettavuudessa, ja se on sovellettava jokaiseen asettelutaulukkoon, sisäkkäiset mukaan lukien, ei vain uloimpaan kääreeseen.

Muutamat liittyvät käytännöt vahvistavat tätä. Älä lisää summary-attribuuttia, <th>-otsikkosoluja, scope-attribuuttia tai <caption>-elementtiä esitystaulukoihin — ne ovat merkitystä kantavaa merkkausta, joka on varattu aidoille datataulukoille. Jos sähköpostisi sisältää todellista taulukkomuotoista dataa, kuten erittelevän kuitin, tee päinvastoin: jätä se datataulukoksi asianmukaisilla <th>-otsikoilla ja scope-attribuuteilla, jotta suhteet välittyvät. Periaate on yhdenmukaisuus ulkoasun ja semantiikan välillä. Tämän saaminen oikein mallipohjakirjastossa on näpertelyä ja helposti taantuvaa, ja siksi se on keskeinen osa sähköpostin korjaus -työtämme.

Kuvat ja alt-tekstit

Kuvat kantavat paljon painoa sähköpostissa, ja monet vastaanottajat näkevät ne oletuksena kuvat poistettuina — jotkin asiakasohjelmat estävät etäkuvat, kunnes käyttäjä sallii ne. Tämä tekee alt-tekstistä kaksinkertaisen tärkeää: se on sekä saavutettavuusvaatimus että varajärjestelmä, joka pitää viestisi ymmärrettävänä, kun kuvat eivät lataudu.

Jokainen <img>-elementti tarvitsee alt-attribuutin. Mitä sen sisälle tulee, riippuu kuvan tarkoituksesta. Informatiiviselle kuvalle — tuotekuva, infografiikka, kaavio — alt-tekstin tulisi välittää sama tieto, jonka kuva tarjoaa. “Sininen juoksukenkä sivulta kuvattuna” on hyödyllisempi kuin “image1.png”, ja kaavion alt-tekstin tulisi tiivistää keskeinen viesti, ei vain merkitä sitä kaavioksi. Kuvaksi renderöidylle tekstille, mitä edelleen tapahtuu mainosotsikoiden kanssa, alt-tekstin on toistettava sanat täsmälleen, koska muuten kyseinen sisältö on näkymätön ruudunlukijoille ja kaikille, joilla on kuvat pois päältä.

Koristeellisille kuville — välistäjät, taustakoristeet, erottimet, jotka eivät lisää mitään merkitykseen — käytä tyhjää alt-attribuuttia, kirjoitettuna muodossa alt="". Tämä kertoo nimenomaisesti ruudunlukijoille ohittaa kuvan sen sijaan, että ilmoittaisi tiedostonimen. Attribuutin jättäminen kokonaan pois ei ole sama asia; puuttuva alt saa ruudunlukijat usein lukemaan kuvan URL-osoitteen, mikä on huonointa kummastakin maailmasta. Ole erityisen varovainen yleisen mallin kanssa, jossa kuvaa käytetään painikkeena tai linkkinä: kyseisen kuvan alt-tekstin on kuvattava toimintoa, kuten “Viimeistele ostoksesi”, ei kuvaa.

Vielä yksi sähköpostikohtainen seikka: älä koskaan laita olennaista tietoa pelkästään kuvaan. Alennuskoodi, vahvistusnumero, peruutuslinkki, ydintoimintakehotus — jos jokin näistä on olemassa vain pikseleinä, ne katoavat kuvat-pois- ja ruudunlukijakäyttäjiltä. Pidä kriittinen sisältö elävänä, valittavana tekstinä.

Kontrasti ja tumma tila

Tekstin on oltava luettavaa, mikä tarkoittaa, että sen on täytettävä kontrastivaatimukset. WCAG 2.2 vaatii vähintään 4,5:1 kontrastisuhdetta normaalille tekstille ja 3:1 suurelle tekstille suhteessa taustaansa. Vaaleanharmaa teksti valkoisella taustalla — minimalistisen sähköpostisuunnittelun ikuinen suosikki — epäonnistuu usein, samoin kuin haaleat painikkeet ja matalan kontrastin linkkivärit. Nämä kynnysarvot pätevät sähköpostiin aivan kuten verkkoonkin, ja samat WCAG 2.2 -onnistumiskriteerit ovat mittapuu; laajempi WCAG-yhteensopivuus -katsauksemme selittää, kuinka nämä kriteerit sopivat yhteen.

Sähköposti lisää mutkan, jota verkossa enimmäkseen ei ole: tumman tilan. Monet asiakasohjelmat — Apple Mail, Outlook, Gmail muiden joukossa — muuntavat sähköpostit automaattisesti, kun käyttäjällä on tumma tila käytössä. Jotkin yksinkertaisesti vaihtavat taustan; toiset kääntävät tai värittävät palettisi aggressiivisesti uudelleen, joskus osittain. Lopputulos on, että painike, jossa on tummaa tekstiä vaalealla brändivärillä, voi päätyä tummaan tekstiin tummalla käännetyllä taustalla, pudottaen kontrastin nollaan. Värillisen laatikon sisällä oleva musta teksti voi muuttua näkymättömäksi. Logot, joissa on läpinäkyvä tausta, voivat kadota tummalla pohjalla.

Tummalle tilalle ei ole yleistä hallintaa, ja olemassa olevat tekniikat vaihtelevat asiakasohjelmittain, mutta puolustavat periaatteet ovat pysyviä. Suunnittele molemmat tilat mielessä. Vältä puhdasta mustaa tai puhdasta valkoista perusväreinä, koska ne eivät jätä asiakasohjelmalle tilaa säätää. Anna logoille ja keskeisille grafiikoille kontrastiraja tai kiinteä taustalevy, jotta ne selviävät kääntämisestä. Testaa todellinen renderöity tulos tummassa tilassa jokaisessa suuressa asiakasohjelmassa sen sijaan, että luottaisit vaalean tilan suunnittelusi kääntyvän. Tavoitteena on, että teksti ja interaktiiviset elementit pysyvät kontrastikynnyksen yläpuolella riippumatta siitä, kumpaan suuntaan asiakasohjelma ne kääntää.

Kuvaavat linkit ja saavutettavat painikkeet

Ruudunlukijan käyttäjät avaavat usein luettelon kaikista viestin linkeistä navigoidakseen tai päättääkseen, minne mennä. Tuossa luettelossa linkkiteksti näkyy riisuttuna ympäröivästä asiayhteydestään. Viesti, joka on täynnä “klikkaa tästä”, “lue lisää” ja “tutustu” -ilmauksia, tuottaa hyödyttömän luettelon identtisiä, merkityksettömiä merkintöjä. Jokaisen linkin tekstin tulisi olla itsessään mielekäs: “Lue kevään kestävyysraporttimme” tai “Seuraa tilaustasi” kertoo käyttäjälle täsmälleen, minne linkki johtaa ilman ympäröivää lausetta.

Sama pätee painikkeisiin, jotka sähköpostissa ovat yleensä painikkeen näköisiksi tyyliteltyjä linkkejä — usein rakennettu “luodinkestävä painike” -tekniikalla käyttäen sisäkkäisiä taulukoita ja taustavärejä, jotta ne renderöityvät asiakasohjelmissa. Rakenteesta riippumatta painikkeen saavutettavan nimen on kuvattava sen toimintoa. Tyhjä tai epämääräinen painike, tai sellainen, jonka teksti elää vain taustakuvassa, on umpikuja avustavalle teknologialle. Jos painike on kuvapohjainen, toiminto kuuluu kuvan alt-tekstiin.

Tee linkki- ja painikekohteista riittävän suuria mukavasti napautettaviksi — WCAG 2.2 esitteli kohdekoon vähimmäismäärän, ja mobiilissa liian pieni napautuskohde turhauttaa kaikkia, ei vain käyttäjiä, joilla on motorisia rajoitteita. Varmista, että linkit ovat erotettavissa muuten kuin pelkän värin avulla, koska pelkkään väriin perustuvat linkit epäonnistuvat heikkonäköisille tai värisokeille käyttäjille; alleviivaus on turvallisin vihje. Ja anna jokaiselle linkille todellinen, toimiva kohde paikkamerkin sijaan. Epämääräinen linkkiteksti on yksi yleisimmistä epäonnistumisista, joita näemme, ja se esiintyy myös verkossa, ei vain sähköpostissa — koosteemme yleisistä saavutettavuusongelmista, joita välttää kattaa saman mallin laajemmassa asiayhteydessä.

Esiotsikko ja esikatselukokemus

Esiotsikko — joskus kutsuttu esikatselutekstiksi — on tekstinpätkä, joka näkyy aiherivin vieressä tai sen alla saapuneissa-kansiossa, ennen kuin viesti avataan. Monet sähköpostit haaskaavat sen, jättäen sen oletukseksi mikä tahansa teksti sattuukin tulemaan ensimmäisenä: “Eikö sähköposti näy oikein?” -rivi, “peruuta tilaus” -linkki tai jono tyhjää alt-tekstiä. Ruudunlukijan käyttäjille, jotka navigoivat saapuneissa-kansiossaan, ja kaikille, jotka päättävät avata, tuo haaskattu esiotsikko on menetetty tilaisuus viestiä.

Kirjoita tarkoituksellinen, mielekäs esiotsikko, joka tiivistää sähköpostin tarkoituksen, ja sijoita se rungon ensimmäiseksi tekstisisällöksi, jotta se on se, mitä saapuneet-kansio poimii. Vakiotekniikka on piilotettu tekstilohko lähellä sähköpostin yläosaa, tyylitelty visuaalisesti piilotetuksi mutta silti asiakasohjelmien ja avustavan teknologian saataville. Ole varovainen sen kanssa, kuinka piilotat sen: huonosti piilotettu esiotsikko voi joko näkyä ei-toivottuna näkyvänä rivinä tai ruudunlukijat voivat ohittaa sen kokonaan. Täytä se asianmukaisesti, jotta loppuosan saapuneet-sisältö ei vuoda viereistä tekstiä esikatseluun.

Kohtele esiotsikkoa osana viestin informaatioarkkitehtuuria. Yhdistettynä selkeään aiheriviin ja vahvaan aloitusotsikkoon se antaa jokaiselle vastaanottajalle — näkevälle tai ei — nopean, tarkan käsityksen siitä, mikä sähköposti on ja miksi sillä on merkitystä.

Responsiivinen asettelu ja zoomaus

Sähköposteja luetaan puhelimilla yhtä paljon kuin työpöydillä, ja niitä lukevat ihmiset, jotka zoomaavat suurentaakseen tekstiä. Molemmat vaativat, että asettelu mukautuu. Kiinteä, leveä asettelu, joka pakottaa vaakasuoran vierityksen pienellä näytöllä tai joka rikkoutuu, kun käyttäjä suurentaa tekstikokoa, on este — ja WCAG 2.2:lla on kriteerit sekä uudelleenjärjestelylle että tekstin välistykselle, jotka pätevät tässä.

Rakenna sähköpostit responsiivisiksi: yksisarakkeinen asettelu kapeilla näytöillä on lähes aina vankin ja saavutettavin valinta, koska se säilyttää lukujärjestyksen ja välttää vierekkäisen sisällön, joka romahtaa arvaamattomasti. Kun käytät mediakyselyitä asetteluiden vaihtamiseen, muista, että jotkin asiakasohjelmat jättävät ne huomiotta, joten oletusrenderöinnin on silti oltava käyttökelpoinen. Aseta fonttikoot riittävän suuriksi luettaviksi ilman zoomausta — noin 14–16 pikseliä pienempi leipäteksti on monille vaikeaa mobiilissa — ja vältä rivikorkeuden tai kirjainvälistyksen kiinnittämistä niin tiukasti, että suurennettu teksti menee päällekkäin tai leikkautuu.

Testaa, mitä tapahtuu, kun käyttäjä zoomaa sisään tai suurentaa laitteensa järjestelmän fonttikokoa. Sisällön tulisi järjestyä uudelleen ja pysyä luettavana sen sijaan, että se ylivuotaisi säiliönsä tai katoaisi muiden elementtien taakse. Palkkio on sähköposti, joka toimii paitsi heikkonäköisille käyttäjille myös kaikille, jotka lukevat pienellä näytöllä epätäydellisissä olosuhteissa.

Testaus asiakasohjelmien ja ruudunlukijoiden välillä

Et voi varmistaa sähköpostin saavutettavuutta pelkkää koodia tarkastelemalla, koska koko haaste on, että asiakasohjelmat renderöivät saman koodin eri tavoin. Testauksen on tapahduttava edustavan asiakasohjelmien ja avustavien teknologioiden kirjon välillä, niissä olosuhteissa, joita todelliset vastaanottajat käyttävät.

Kata vähintään suuret asiakasohjelmat: Outlook (työpöytä Windowsissa sekä verkko- ja uudet versiot), Gmail (verkko ja mobiilisovellus) ja Apple Mail (macOS ja iOS). Tarkista jokaiselta renderöinti sekä vaaleassa että tummassa tilassa, kuvat päällä ja pois, ja suurennetulla zoomilla. Lisää sitten ruudunlukijat päälle — VoiceOver Apple Mailin kanssa macOS:ssä ja iOS:ssä, NVDA tai JAWS Outlookin ja Gmailin kanssa Windowsissa, ja TalkBack Gmail-sovelluksen kanssa Androidissa. Kuuntele sähköpostia niin kuin ruudunlukijan käyttäjä tekisi: ilmoitetaanko otsikot, onko lukujärjestys looginen, ovatko asettelutaulukot hiljaisia, ovatko linkit mielekkäitä linkkiluettelossa, ilmoittavatko kuvat hyödyllistä alt-tekstiä vai pysyvätkö hiljaa, kun ne ovat koristeellisia?

Automaattisilla tarkistuksilla on paikkansa — ne voivat merkitä puuttuvat alt-attribuutit, matalan kontrastin ja puuttuvat kieliattribuutit nopeasti monien mallipohjien yli — mutta ne eivät voi arvioida, onko alt-teksti mielekästä, kertooko lukujärjestys oikean tarinan tai kuvaako painikkeen nimi sen toimintoa. Tämä arviointi vaatii manuaalista testausta, ihanteellisesti mukaan lukien testaus ihmisillä, jotka käyttävät avustavaa teknologiaa joka päivä. Manuaalisten saavutettavuusauditointien oppaamme selittää, miksi ihmistestaus on korvaamatonta, ja vammaisten henkilöiden tekemät auditoinnit tuovat juuri tuon eletyn kokemuksen näkökulman sähköpostiin.

Varoituksen sana: älä lankea saavutettavuuden “peite”-widgetteihin, jotka lupaavat välitöntä vaatimustenmukaisuutta. Ne eivät toimi verkkosivustoille, ja ne ovat merkityksettömiä sähköpostille, jossa ei ole sivua, johon injektoida skripti. Todellinen sähköpostin saavutettavuus tulee merkkauskielen korjaamisesta, ei päälle liimattavasta.

Mallipohjien korjaaminen ESP-tasolla

Yhden sähköpostin korjaaminen on hyödyllistä. Sen lähteen korjaaminen, joka generoi jokaisen sähköpostin, on mullistavaa. Useimmat organisaatiot lähettävät sähköpostipalveluntarjoajan kautta — Mailchimp, Klaviyo, Salesforce Marketing Cloud, Braze ja vastaavat — jossa kampanjat kootaan päämallipohjista, uudelleenkäytettävistä moduuleista ja raahaa-ja-pudota-sisältölohkoista. Jos nämä taustalla olevat mallipohjat kantavat saavutettavuuskorjaukset, jokainen tuleva lähetys perii ne automaattisesti, eikä markkinointitiimin tarvitse muistaa tarkistuslistaa jokaiselle kampanjalle.

Tämä on kustannustehokkain paikka panostaa. Korjaa päämallipohja niin, että asettelutaulukot kantavat role="presentation"-attribuutin, kieliattribuutti on asetettu, esiotsikon rakenne on paikallaan ja otsikkoteline on oikein. Korjaa jokainen uudelleenkäytettävä moduuli — hero-lohko, artikkelikortti, painike, alatunniste — niin että mitä tahansa tiimi raahaa sisään, on rakenteeltaan saavutettava. Luo mallit alt-tekstille, jotta toimittajia kehotetaan kirjoittamaan se, ja leivo kontrastiturvalliset, tumman tilan huomioivat värit brändipalettiin, jota mallipohjat käyttävät.

Mutta raahaa-ja-pudota-rakentajat voivat myös taannuttaa saavutettavuutta: rakentaja saattaa poistaa role="presentation", sotkea merkkauskielen viennissä tai antaa toimittajan liittää saavuttamattoman lohkon. Joten mallipohjien korjaaminen on yhdistettävä hallintaan — ohjeisiin, tarkistusvaiheisiin ja säännölliseen uudelleentestaukseen ESP:n ja sen vientikäyttäytymisen muuttuessa. Siinä saavutettavuuden rakentaminen työnkulkuun maksaa itsensä takaisin; saavutettavuusprosessin parantaminen -palvelumme auttaa tiimejä tekemään saavutettavasta sähköpostista oletusarvon jälkikäteisajatuksen sijaan, ja saavutettavuuskonsultointi sovittaa sen yhteen laajemman vaatimustenmukaisuusohjelmasi kanssa. Organisaatioille, joita Euroopan esteettömyysdirektiivi koskee, saavutettavat asiakasviestinnät ovat osa kuvaa, minkä EAA-yhteensopivuus -katsauksemme esittää.

QualiBooth yhdistää saavutettavuuden skannausohjelmiston ongelmiin, jotka koneet havaitsevat luotettavasti, asiantuntevaan manuaaliseen korjaukseen harkintaa vaativiin tapauksiin, joita ne eivät kykene — verkkosivustojen, asiakirjojen ja sähköpostien välillä. Jos sähköpostisi ovat osa sitä, miten palvelet asiakkaita, ne ansaitsevat saman tarkkuuden kuin muu digitaalinen omaisuutesi.

Yhteenveto

Sähköpostin saavutettavuus ei ole verkkosaavutettavuuden pienempi versio — se on siihen liittyvä mutta erillinen erikoisala, jonka muovaa pirstaloitunut asiakasohjelmamaisema, taulukkopohjaiset asettelut ja renderöintimoottorit, jotka jättävät huomiotta suuren osan nykyaikaisesta verkosta. Hyvä uutinen on, että tekniikat ovat vakiintuneita: semanttinen rakenne ja vankka otsikkorakenne, role="presentation" jokaisessa asettelutaulukossa, mielekäs alt-teksti tyhjällä altilla koristeelle, kontrasti, joka selviää tummasta tilasta, linkit ja painikkeet, jotka kuvaavat itsensä, tarkoituksellinen esiotsikko, responsiiviset asettelut, jotka kestävät zoomausta, ja kurinalainen testaus asiakasohjelmien ja ruudunlukijoiden välillä. Sovella niitä mallipohjatasolla ja saavutettavuus lakkaa olemasta kampanjakohtainen rasite ja siitä tulee järjestelmäsi ominaisuus.

Hyöty on todellinen. Saavutettavat sähköpostit tavoittavat enemmän ihmisiä, lukeutuvat selkeästi kuvat pois päältä ja yleensä suoriutuvat paremmin, koska selkeys ja vankkuus auttavat kaikkia. Jos haluat apua, sähköpostin korjauspalvelumme voi auditoida mallipohjasi, korjata ne ESP-tasolla ja varmistaa tuloksen koko asiakasohjelmien kirjon yli — ja voit pyytää demon tai suorittaa ilmaisen skannauksen verkkosivustostasi nähdäksesi, missä loput digitaalisesta omaisuudestasi ovat.

Usein kysytyt kysymykset

Tarvitsenko todella role="presentation"-attribuutin jokaisessa asettelutaulukossa? Kyllä. Ilman sitä ruudunlukijat ilmoittavat jokaisen asettelutaulukon datataulukkona, lukien rivien ja sarakkeiden määrät ja häiriten kulkua. Koska sähköpostiasettelut sisältävät sisäkkäisiä taulukoita, attribuutin on oltava jokaisessa asettelutaulukossa, ei vain ulommassa kääreessä. Aidot datataulukot, kuten kuitit, säilyttävät sen sijaan datasemantiikkansa.

Mitä minun pitäisi laittaa koristeellisen kuvan alt-tekstiin? Käytä tyhjää alt-attribuuttia, kirjoitettuna alt="", jotta ruudunlukijat ohittavat kuvan. Älä jätä attribuuttia kokonaan pois, koska puuttuva alt saa usein kuvan tiedostonimen tai URL-osoitteen luettavaksi ääneen.

Kuinka estän tummaa tilaa rikkomasta sähköpostiani? Et voi täysin hallita, kuinka kukin asiakasohjelma käsittelee tummaa tilaa, mutta voit suunnitella puolustavasti: vältä puhdasta mustaa ja valkoista, anna logoille kontrastiraja tai tausta, pidä kontrasti WCAG 2.2 -kynnysten yläpuolella ja testaa renderöity tulos tummassa tilassa jokaisessa suuressa asiakasohjelmassa sen sijaan, että olettaisit vaalean tilan suunnittelusi siirtyvän.

Voiko automaattinen työkalu tehdä sähköpostistani saavutettavan? Automaattiset työkalut havaitsevat joitakin ongelmia — puuttuvat alt-attribuutit, matalan kontrastin, puuttuvat kieliasetukset — mutta ne eivät voi arvioida, onko alt-teksti mielekästä, onko lukujärjestys järkevä tai kuvaavatko linkit ja painikkeet tarkoituksensa. Se vaatii manuaalista testausta ruudunlukijoilla. Saavutettavuuden peite-widgetit eivät ole ratkaisu eivätkä sovellu sähköpostiin.

Onko parempi korjata yksittäisiä sähköposteja vai mallipohjia? Mallipohjia. Päämallipohjien ja uudelleenkäytettävien moduulien korjaaminen ESP:ssäsi tarkoittaa, että jokainen tuleva lähetys perii korjaukset, mikä on paljon kustannustehokkaampaa kuin kampanjoiden korjaaminen yksi kerrallaan. Yhdistä se hallintaan, jotta raahaa-ja-pudota-rakentajat eivät tuo ongelmia uudelleen.