Nyheder

Aktive projekter

Senest opdateret 31. oktober 2026

I gang

v3: En komplet kvalitetssikringspakke

27. september 2026

Afsløret på DrupalCon Europe 2026

Vigtigste nye funktioner

• Testkernen er lagt sammen med Sa11y. Det nye, fælles udviklede regelsæt føjer udviklertests, kontrasttjek og læsbarhedsvurdering til det centrale regelsæt for indholdstests.
• Understøttelse af flere sprog
• Byggeværktøj til brugerdefinerede tjek
• Vedligeholdelsesværktøjer til dashboardet
• Et værktøj til crawling af sitet, der tilføjer nye resultater.
• Gør det muligt for bestemte tests (er denne PDF tilgængelig?) at afvise advarsler på hele sitet for bestemte roller.
• Opdelt konfiguration: særskilte tests og rapportvisninger for henholdsvis udvikler- og indholdsroller.

Og måske vigtigst af alt for projektets fremtid:

• Vi fik en bevilling til at starte denne sponsororganisation, der skal støtte eksisterende brugere og finansiere arbejdet med fremtidige projektideer.

v2: Afvisninger og rapporter

2. marts 2023

For to år siden præsenterede vi tilgængelighedstjekkeren Editoria11y som et nøglefærdigt plugin til Drupal, der skulle give forfattere øjeblikkelig, automatisk feedback med nyttige tips til at forbedre deres indhold.

Vi mente, at det ville dække et udækket behov. De eksisterende muligheder krævede alle oplæring og flittig brug for at gøre nytte, og erfaringen havde vist os, at det ikke var nogen effektiv løsning at forsøge at oplære og overvåge tusindvis af indholdsforfattere i en stor organisation. Vi var sikre på, at et program kun kunne lykkes med en høj grad af automatisering, hvor indholdsforfattere fik høflig »oplæring i rette øjeblik«, når det opdagede almindelige fejl.

Det virkede.

På Princeton vendte det stort set min kommunikation på hovedet. På de platforme, hvor det var installeret, gik vi fra at sende den ene ensartede mail efter den anden til indholdsforfattere med anmodninger om alt-tekst og bedre links og overskrifter til at modtage spørgsmål fra indholdsforfattere om, hvordan de kunne forbedre deres tekster, så de ikke blev markeret så tit.

Udadtil var reaktionen begejstring:

Selvstændige tips

I v1-tipsene valgte vi en »resumé og detaljer«-tilgang: en kort forklaring af problemet og et link til flere detaljer.

Det var en forbedring i forhold til værktøjer skrevet til udviklere: Tipsene var korte og klare. Men valget af, hvor der skulle linkes hen, var altid et problem. Flere brugere i det offentlige og på uddannelsesinstitutioner følte sig nødsaget til at ændre tipsene for at fjerne links til Princetons dokumentation, hvilket gav dem ekstra arbejde. Så vi omskrev standardtipsene, så de står alene, med eksempler direkte i teksten.

Skelnen mellem røde advarsler (sikre problemer) og gule advarsler (mulige problemer) viste sig at være forvirrende og til tider irriterende.

Så vi gjorde de gule advarsler til »manuelle tjek« for at tydeliggøre deres betydning og tilføjede knapper, så forfattere kan afvise advarsler. »Ignorerede« advarsler skjules kun for den person, der klikker; advarsler »markeret som OK« skjules for alle sitets redaktører. Webstedsadministratorer kan vælge, hvem der har tilladelse til hvad.

Oprettelse af et dashboard

Webstedsejere klagede ofte over, at værktøjet gjorde et fremragende stykke arbejde med at finde problemer overalt på sitet, men at der ikke var nogen måde at se en rapport for hele sitet på.

Omskrivningen tilføjer en mulighed for at synkronisere resultaterne tilbage til sitets database. Webstedsejere kan nu gennemse resultaterne efter side eller problem og se, hvilke problemer der er blevet ignoreret eller markeret som OK – og gendanne problemet, hvis de er uenige!

Rundvisning i v2-koden for udviklere

V2 var næsten en komplet omskrivning. Blandt de nye funktioner er:

• Når jQuery-afhængigheden er fjernet, kan det installeres på flere platforme, og ydelsen bliver fordoblet.
• Tjekkeren kan nu konfigureres til at kigge i flere uafhængige dele af siden (fx artiklens indhold og sidefoden).
• Tjekkeren kan nu teste elementer i shadow DOM, som bruges af forskellige webkomponenter og JavaScript-biblioteker.
• Mange nye parametre gør platformintegrationer lettere, fx automatisk at ignorere alle problemer på bestemte sider for bestemte brugere, hvis de ikke er ansvarlige for indholdet på siden, men stadig kan have lyst til at se resultaterne efter behov.
• Tjekkeren leveres nu med flere grundtemaer og parametre til at tilpasse farver.
• Automatiseret test hjælper med at forhindre regressioner i koden.

A11yTalks 2024

11. juni 2024

Drupal GovCon 2023

27. oktober 2023

DrupalCamp NJ 2023

28. marts 2023

v1: Inline-hjælp

11. marts 2021

Det er kompliceret at skabe webindhold med høj tilgængelighed, og det starter gerne med en masse oplæring.

Velkendte vaner skal frarådes:

• Tabeller bør ikke bruges til at lave falske kolonner
• Brødtekst bør ikke centreres eller sættes med lige margener
• Ren visuel formatering (skrifttykkelse og -størrelse) bør ikke være det eneste, der formidler betydning til brugere, som måske hører indholdet eller ser det i »læsetilstand«

Nye vaner skal fremmes:

• Billeder skal have alternativ tekst, der giver mening i sammenhængen
• Sider skal have en reel struktur
• Links bør have meningsfulde titler

Nogle af vores oplæringsforløb sættes naturligvis i gang, fordi vi underviser i nye begreber, men på et tidspunkt må man spørge: Hvor meget af behovet for nye færdigheder skyldes, at begreberne er nye, og hvor meget skyldes, at vi indfører nye forventninger uden at opdatere vores værktøjer? At noget er nyt, betyder ikke, at det ikke kan være intuitivt.

Hvad stavningens historie kan lære os

Fase 1: Giv forfatteren skylden

Fra den skrevne histories begyndelse og helt frem til begyndelsen af 1980'erne gav vi forfatteren skylden, når et ord var stavet forkert. Det var forfatterens ansvar at lære at stave ordentligt.

Hvordan blev man så bedre til at stave? Det her kommer til at lyde bekendt:

1. Man fik undervisning, hos en privatlærer eller i et klasseværelse
2. Man fik udleveret lister, retningslinjer og ordbøger at studere – en tradition, der går helt tilbage til oldtidens kileskriftsleksika indridset i ler.

Fase 2: Giv ordbogen skylden

Men i 1980'erne skete der noget: Lad os kalde det »stavning, fase 2«. De mest populære tekstbehandlingsprogrammer fik stavekontrol.

Og hvad skete der så med skyldfordelingen? Næsten fra den ene dag til den anden flyttede skylden over på værktøjet:

• Ved du ikke, hvordan et ord staves? Gæt, og håb på et match. Hvis der ikke er et, giver du ordbogen skylden.
• Bruger du et rigtigt ord, som ordbogen markerer, fordi den ikke kender det? Brok dig, og beslut, om du vil ignorere understregningen eller højreklikke og føje ordet til ordbogen.

Fjernede stavekontrollen alle vores stavefejl? Bestemt ikke. Men den hjalp. Og den flyttede en stor del af byrden og ansvaret fra forfatteren til maskinen.

Men det var ikke enden på historien …

Fase 3: Giv forfatterværktøjet skylden

De senere år har bragt endnu et skridt fremad: Computere er begyndt at stave for os:

• Prædiktive algoritmer prøver at gætte det næste ord, den næste sætning, måske endda et helt svar på en sms.
• Autoformateringsværktøjer prøver at omdanne stjerner, tal og bogstaver til lister og at omdanne genvejskoder til specialtegn og emoji osv.
• Dikteringsværktøjer prøver at genkende begreber for at vælge mellem homonymer.

Og hvem får skylden, når det går galt? Værktøjet!

Opsamlingssider på sociale medier elsker det pinlige »Det var ikke det, jeg mente!«-skærmbillede.

Editoria11y er et skridt hen imod fase 2

På vores kurser taler vi meget om test og præsenterer flere ganske gode testværktøjer. Ingen af dem kan fange alt: Begreber som »undgå at forklare ting gennem farve- eller rumlige henvisninger« skal tjekkes af et menneske; værktøjer fanger typisk knap halvdelen af de reelle problemer, et site kan have. Men værktøjerne er rigtig gode til at fange mange almindelige fejl i redaktionelt indhold.

Der er dog tre problemer:

1. De fleste er manuelle værktøjer. Indholdsskaberen skal være blevet lært at bruge dem, skal huske, at de findes, mens indholdet skrives, og skal huske at køre dem, når det er færdigt. De tre svage led sammensværger sig om at efterlade meget (det meste?) indhold utjekket.
2. De markerer for meget. De markerer ikke kun de fejl, forfatteren lige har begået, men også farveproblemer fra designeren, tekniske problemer fra udvikleren, strukturelle elementer til orientering osv. Det hæver barren for oplæringen: Forfattere skal ikke kun forstå værktøjet, de skal også lære at ignorere en liste af falske positiver eller helt reelle ting, som det ikke er deres ansvar at rette i dag, mens de skriver netop denne artikel.
3. De automatiserede værktøjer følger typisk et crawl-sitet-og-besøg-dashboardet-paradigme. Igen: Det forudsætter, at en forfatter er blevet oplært i at besøge dashboardet og husker at gøre det.

Så Princeton gik i gang med at lave noget nyt: en automatisk tjekker, integreret i websitet, som kun ville kigge efter almindelige redaktionelle fejl.

Automatisk er … svært.

1. Automatiske tjekkere skal være diskrete: Er de for påtrængende, afbryder og frustrerer de forfatteren. Er de for høflige, kan de let blive til baggrundsstøj, man ignorerer.
2. Automatiske tjekkere skal have en høj ydelse: Hvis siden hakker eller tøver, mens de kører, kommer forfatterne til at ærgre sig over dem og slå dem fra.
3. Automatiske tjekkere skal have begyndervenlige tips. For mange forfattere er det første gang, de hører om den opmærkning, den struktur og det sprog, der gør deres indhold mere tilgængeligt. Advarsler skal være på et enkelt, ikke-teknisk sprog med praktiske råd til at forbedre indholdet.

Så vi startede med det værktøj, der kom tættest på disse mål: Sa11y fra Toronto Metropolitan University. Vi overtog dets testarkitektur og dets brugervenlige tilgang med informationspanel og tooltips og brugte et halvt år på at tilpasse værktøjet, så testene altid kørte automatisk, optimere ydelsen, finjustere tooltips og lave en lang liste af konfigurationsmuligheder, som en udvikler hurtigt kunne bruge til at tilpasse det til en hvilken som helst platform.

Sådan ser det ud i dag:

Når en forfatter er logget ind på sitet, viser Editoria11y's knap antallet og typen af problemer (bestået, manuelle tjek nødvendige, sandsynlige problemer fundet) på hver side. Et klik viser markeringer og tips direkte i indholdet. Hvis fejlen er ny, fordi forfatteren ser på en side, vedkommende lige har redigeret, åbner panelet automatisk.

Pr. marts 2021 betyder det, at mere end 400 Princeton-websites automatisk tjekker for:

• En god dokumentstruktur
  • Oversprungne overskriftsniveauer
  • Tomme overskrifter
  • Meget lange overskrifter
  • Mistænkeligt korte blokcitater, der i virkeligheden kan være overskrifter.
• Tekstalternativer
  • Billeder uden alt-tekst
  • Billeder med et filnavn som alt-tekst
  • Billeder med meget lang alt-tekst
  • Alt-tekst med overflødige ord som »billede af« eller »foto af«
  • Billeder i links med alt-tekst, der lader til at beskrive billedet i stedet for linkets destination
  • Indlejrede visualiseringer, der normalt kræver et tekstalternativ
• Meningsfulde links
  • Links uden tekst
  • Links, der har et filnavn som titel
  • Links, hvis titel kun er generisk tekst: »klik her«, »læs mere«, »download« osv.
  • Links, der åbner i et nyt vindue uden et ikon for eksternt link
• Generel kvalitetssikring
  • At der bruges listeformatering i stedet for stjerner, tal og bogstaver
  • STORE MÆNGDER TEKST MED CAPS LOCK
  • Tabeller uden overskrifter og tabeller med dokumentoverskrifter (»Overskrift 3«) i stedet for tabeloverskrifter (<th>)
  • Links til PDF'er og andre dokumenter med en påmindelse om at teste det downloadede for tilgængelighed eller stille et alternativt, tilgængeligt format til rådighed
  • Indlejrede videoer med en påmindelse om at tilføje undertekster
  • Indlejret lyd med en påmindelse om at stille en transskription til rådighed
  • Indlejringer fra sociale medier med en påmindelse om at tilføje alt-elementer

Vi har frigivet JavaScript-biblioteket til fællesskabet, lavet en nøglefærdig Drupal-integration og er gået i gang med en nøglefærdig WordPress-integration.

På vej mod fase 3: Tilgængelig som standard

På mange måder er Editoria11y en nødløsning. De fleste af de fejl, det fanger, opstod, fordi vi stillede nye forventninger til indholdsforfattere (»opmærk dit indhold med en god struktur«), men gav dem værktøjer, der tilskyndede til det modsatte.

Vejen frem er at gøre det lettere og så automatisk som muligt at skabe tilgængeligt indhold. Hvordan det kommer til at se ud, er endnu ikke klart, men det omfatter nok ting som:

• At gentænke hvilke muligheder der er til rådighed. Hvis vi for eksempel bliver ved med at fortælle brugerne, at de ikke skal bruge lige margener på nettet, er det så ikke på tide at pensionere knappen »lige margener«?
• At gentænke standardindstillingerne. For eksempel har standardtabellen i de fleste CMS'er ikke overskrifter. Det er brugerens ansvar at vide, at man skal klikke på »egenskaber« og tilføje tilgængelighedsfunktioner; måske er det på tide at vende det om?
• At overveje forudsigende formatering og »vink undervejs i arbejdet«. Hvis en bruger gør en hel linje fed, kan vi så foreslå, at den bliver en overskrift? Hvis en bruger vil vælge en overskrift, kan vi så gætte, hvilke overskriftsniveauer vedkommende ønsker, i stedet for at give seks valgmuligheder? Kan vi give oplæring i rette øjeblik i svære begreber?