Hur säkerställer du att dokument som genereras av system – förmodligen de flesta dokument idag – är tillgängliga för användare och följer tillgänglighetslagstiftningen? Låt oss fördjupa oss i det ämnet i den här artikeln!
Vad är problemet?
När man lär sig om tillgängliga dokument fokuserar nästan all vägledning på manuellt skapade filer: hur man taggar en PDF för hand, hur man exporterar ett Word-dokument korrekt och så vidare.
Men tänk på de senaste dokumenten du fick som var personliga för dig. Kanske en:
- lånelöfte från din bank
- lönespecifikation
- skatteinformation
- digitalt kvitto
Dessa dokument genereras nästan alltid av system.
Om de kommer från en organisation som omfattas av tillgänglighetslagstiftning (offentlig sektor, banker, e-handel, etc.), måste dokumenten vara tillgängliga — oavsett hur de produceras.
I praktiken innebär att göra dokumentet tillgängligt att säkerställa att:
- dokumentet är korrekt taggat
- rubriker, tabeller, listor och så vidare är korrekt markerade
- bilder har alt-text som beskriver dem
- färgkontrasten mellan text och viktiga grafiska element är tillräcklig
Kort sagt: hjälpmedel som skärmläsare måste kunna förstå strukturen och innehållet.
Exempel: ett otillgängligt systemgenererat dokument
Här är ett klassiskt exempel på ett otaggat dokument. Tillgänglighets-taggpanelen, som jag har öppnat i Adobe Acrobat Pro, visar “Inga taggar tillgängliga”:
Utan taggar kan hjälpmedel som skärmläsare inte tolka innehållet på ett meningsfullt sätt. Många synskadade användare navigerar i dokument genom att hoppa mellan rubriker — något som helt enkelt är omöjligt när rubriker inte är taggade.
Exempel: ett tillgängligt systemgenererat dokument
Här är ett tillgängligt dokument.
Observera att taggträdet innehåller meningsfull struktur:
- <H1>, <H2> and so on for headings
- <P> for paragraphs
- <Table>, <TH>, <TD> for tables (TH and TD stand for table header and table data)
- <L> and <LI> for lists (List and List Item)
Denna struktur är avgörande för att göra dokumentet tillgängligt och användbart för användare av hjälpmedel.
Ta reda på hur tillgängliga dina systemgenererade dokument är
Om du har Adobe Acrobat Pro är detta ganska enkelt:
- Öppna panelen Tillgänglighets-taggar
- Kör Adobes tillgänglighetskontroll
Du får snabbt en översikt över vad som fungerar och vad som inte gör det.
Ingen Acrobat Pro? Kontakta oss så hjälper vi dig med en första bedömning: contact@enit.se
Tre sätt att närma sig utmaningen
Det finns tre vanliga strategier för att förbättra tillgängligheten i systemgenererade dokument, och vilken du väljer beror sannolikt på din organisations nuvarande situation.
- Systemuppgradering eller migrering – vi kan kalla detta “Tillgänglighet från grunden”.
- Tillgänglighets-tillägg – “Tillgänglighet genom åtgärder”
- Ändra till HTML (med PDF som alternativ) – “Tillgänglighet som standard”
Låt oss gå igenom dem en efter en!
1. Systemuppgradering eller migrering – “Tillgänglighet från grunden”
Detta är det mest robusta — men också det mest tidskrävande — tillvägagångssättet för att uppnå tillgänglighet i systemgenererade dokument.
Fördelar:
- Engångsinsats för implementering
- Långsiktig, underhållsbar lösning
- <span”>Supports all aspects of accessibility, not only technical compliance
Nackdelar:
- Kan vara tidskrävande och komplex
- Kan kräva en ny installation
- Adresserar inte historiska dokument
De flesta systemgenererade dokument produceras med hjälp av ett system för kundkommunikationshantering (CCM). De tre stora CCM-leverantörerna är opentext, Quadient och Smart Communications.
Alla tre erbjuder plattformar som stöder generering av tillgängliga PDF:er, inklusive:
- OpenText
- Quadient Inspire Flex
- Quadient Inspire Evolve
- Smart Communications SmartCOMM
Stödet för tillgänglighet i dessa plattformar har mognat avsevärt de senaste åren. När de körs på de senaste versionerna erbjuder alla tre leverantörer starkt stöd för tillgänglig PDF-utdata.
Att införa tillgänglighet genom en systemuppgradering kräver att alla dokumentmallar granskas och uppdateras med korrekt semantisk struktur och taggning. Detta inkluderar korrekt hantering av rubriker, tabeller, bilder, listor och andra artefakter som påverkar användarupplevelsen för användare av hjälpmedel som skärmläsare.
Organisationen måste besluta om migrationsstrategin – om man ska utföra en 1:1-migrering eller rationalisera mallar. Vi rekommenderar generellt att börja med workshops för mallrationalisering för att minska omfattningen och identifiera synergier. Detta tillvägagångssätt har visat sig vara effektivt för att förkorta tiden till marknaden samtidigt som det framtidssäkrar CCM-installationen.
En systemuppgradering stöder tillgänglighet från grunden för alla nya dokument. Den gör det också möjligt för organisationer att inte bara hantera teknisk efterlevnad, utan även kvalitativa aspekter som tydligare språk, förbättrad typografi och bättre kontrast – vilket resulterar i en mer inkluderande användarupplevelse. I många fall är detta också ett lämpligt tillfälle att se över CCM-lösningen som helhet.
Men om tillgänglighetsinitiativet är föremål för snäva tidsfrister kan detta tillvägagångssätt vara utmanande på grund av implementeringstiden och, beroende på vald plattform, högre kostnader.
2. Tillgänglighetstillägg – ”Tillgänglighet genom efterbearbetning”
Med detta tillvägagångssätt läggs tillgänglighetsfunktioner som taggning och läsordning till efter att PDF:en har genererats. PDF:ens visuella layout och innehåll förblir oförändrade, även om innehållsuppdateringar naturligtvis kan hanteras separat vid behov.
Fördelar:
- Kort tid till marknaden
- Källagnostisk (beroende på licensmodell)
- Kan stödja historiska dokument
Nackdelar:
- Ökad komplexitet på grund av dubbla kodbaser (CCM + efterbearbetning)
- Adresserar primärt teknisk tillgänglighet
Efterbearbetning av dokument är ett snabbt och effektivt sätt att skapa värde tidigt i ett tillgänglighetsinitiativ. Både opentext och Quadient tillhandahåller verktyg för efterbearbetning:
- opentext Tillgänglighetstillägg
- Quadient Inspire Adapt
Om de tekniska förutsättningarna är uppfyllda – såsom en lämplig CCM-projektuppsättning eller kompatibla källsystem – kan åtgärdsarbetet delas upp i flera parallella strömmar. Detta gör att tillvägagångssättet är väl lämpat för projekt med snäva tidsfrister.
De främsta fördelarna är snabbhet och flexibilitet. Tillvägagångssättet kan i stort sett vara källsystemsoberoende, och beroende på licensmodell kan det även stödja både nya och historiska dokument. Implementeringen är vanligtvis okomplicerad.
Åtgärderna introducerar dock två separata kodbaser: en för dokumentgenerering och en för PDF-åtgärder. Detta kräver disciplinerad styrning, kontrollerad förändringshantering och ett robust testramverk för att säkerställa att båda lagren förblir synkroniserade över tid.
3. Byte till HTML (med PDF som alternativ)
Att leverera innehåll i HTML-format resulterar ofta i betydligt högre tillgänglighet. HTML är i sig väl lämpat för hjälpmedelstekniker och erbjuder starkt stöd för semantisk struktur, responsivitet, navigering och användarstyrd presentation. För många användningsfall kan HTML därför fungera som det primära leveransformatet, medan PDF behålls som en säkerhetskopia eller arkivversion.
Fördelar
- Högre tillgänglighetsnivå kan uppnås
- Låga kostnader för programvara och verktyg
- PDF kan behållas som komplement eller för juridiska, revisions- och arkiveringsändamål
Nackdelar
- Inte lämpligt som ersättning för PDF:er i alla juridiska sammanhang
- Kräver utrednings- och modelleringsarbete
- Potentiellt dubbelt underhåll (HTML-leverans och PDF-generering)
I digitala inkorgar interagerar användare vanligtvis med transaktionsinformation via en HTML-baserad vy optimerad för tillgänglighet och användbarhet, samtidigt som de har möjlighet att ladda ner motsvarande PDF för referens eller lagring vid behov.
Ett HTML-baserat brev i digitala inkorgar blir lätt att läsa med hjälpmedelstekniker, texten är vanligtvis skalbar, bland andra fördelar.
Detta tillvägagångssätt flyttar fokus från att göra PDF:er tillgängliga till att säkerställa att användare får information i ett format som är tillgängligt som standard. PDF:en genereras och lagras fortfarande där det krävs – till exempel för juridisk efterlevnad, revision eller långtidsarkivering – men den är inte längre det primära gränssnittet för slutanvändaren.
När är ett HTML-först-tillvägagångssätt lämpligt?
Ur ett CCM-perspektiv är detta tillvägagångssätt särskilt relevant när:
- En fullständig systemuppgradering inte är omedelbart genomförbar
- Tillgänglighetslagstiftning, såsom European Accessibility Act (EAA), fortfarande måste uppfyllas
- Dokumenten är primärt informativa snarare än juridiskt bindande
I dessa situationer kan organisationer leverera innehåll i HTML samtidigt som PDF:en behålls som ett kompletterande, sekundärt eller reservformat. Detta möjliggör framsteg mot tillgänglighetskrav utan att fördröja långsiktiga moderniseringsinitiativ för CCM.
Ett HTML-först-tillvägagångssätt möjliggör också förbättringar av språkklarhet, struktur, typografi och kontrast – liknande vad som är möjligt i en fullt uppgraderad CCM-miljö. Visst utrednings- och modelleringsarbete kan krävas för att extrahera eller omstrukturera dokumentlogik, särskilt för äldre mallar, men detta tillvägagångssätt erbjuder ofta en pragmatisk och skalbar väg till tillgänglighet.
Var ska man börja?
Börja med att identifiera vilket tillvägagångssätt – eller kombination av tillvägagångssätt – som bäst passar din organisations dokumentlandskap, tidsramar och regelverk.
Boka ett möte med Axess Lab och Enit, så hjälper vi dig att bedöma din nuvarande situation och definiera den mest effektiva vägen framåt: contact@enit.se
Denna artikel är ett samarbete med Axess Lab
Den skrevs av Lisa Huge, ENIT, och Hampus Sethfors, Axess Lab, för ett webbinarium som hölls tillsammans av ENIT och Axess Lab.
Här är en länk till det inspelade webbinariet.
Här är en länk till hur ENIT kan hjälpa dig med tillgänglighet ENIT Accessibility LAB
