Nyheter

Aktiva projekt

Senast uppdaterad 31 oktober 2026

Pågående

v3: En komplett svit för kvalitetssäkring

27 september 2026

Premiär på DrupalCon Europe 2026

Viktiga nya funktioner

• Gemensam testkärna med Sa11y. Den nya, gemensamt utvecklade regeluppsättningen lägger till utvecklartester, kontrastkontroll och läsbarhetspoäng i de centrala innehållstesterna.
• Stöd för flera språk
• Byggverktyg för anpassade kontroller
• Underhållsverktyg för kontrollpanelen
• Ett verktyg för genomsökning av webbplatsen som lägger till nya resultat.
• Gör det möjligt för vissa roller att avfärda varningar på hela webbplatsen för vissa tester (är den här PDF-filen tillgänglig?).
• Delad konfiguration: rollbaserade tester och rapportvyer, separata för utvecklare och innehållsredaktörer.

Och, kanske viktigast av allt för projektets framtid:

• Vi fick ett anslag för att starta den här sponsorsorganisationen, som ska ge stöd till befintliga användare och finansiera arbete med framtida projektidéer.

v2: Avfärdanden & rapporter

2 mars 2023

För två år sedan presenterade vi tillgänglighetsgranskaren Editoria11y, ett nyckelfärdigt insticksprogram för Drupal som ger redaktörer automatisk, omedelbar återkoppling och hjälpsamma tips för att förbättra innehållet.

Vi trodde att det här skulle fylla ett tomrum. Alla befintliga alternativ krävde utbildning och flitig användning för att vara till nytta, och erfarenheten hade visat oss att det inte är ett effektivt sätt att angripa problemet att försöka utbilda och övervaka tusentals redaktörer i en stor organisation. För att ett program skulle lyckas var vi övertygade om att det behövde en hög grad av automatisering och artigt ge redaktörer ”utbildning precis när den behövs” när det upptäckte vanliga misstag.

Det fungerade.

På Princeton vände det i stort sett på riktningen i min kommunikation. På plattformar där det var installerat gick vi från att skicka upprepade mejl till redaktörer med önskemål om alt-text och bättre länkar och rubriker, till att ta emot frågor från redaktörer om hur de kunde förbättra sina texter så att de inte flaggades så ofta.

Utanför Princeton möttes det av rent jubel:

Att skriva fristående tips

Vi valde en ”sammanfattning och detaljer”-metod för tipsen i v1: en kort förklaring av problemet och en länk till mer information.

Det var en förbättring jämfört med verktyg skrivna för utvecklare: tipsen var korta och tydliga. Men frågan om vart vi skulle länka var ständigt ett problem. Flera användare inom offentlig sektor och högre utbildning kände sig tvungna att ändra tipsen för att ta bort länkarna till Princetons dokumentation, vilket gav dem extra arbete. Så vi skrev om standardtipsen så att de blev fristående, med exempel direkt i texten.

Skillnaden mellan röda varningar (konstaterade problem) och gula varningar (möjliga problem) visade sig vara förvirrande och ibland irriterande.

Därför gjorde vi om de gula varningarna till ”manuella kontroller” för att förtydliga vad de betyder, och lade till knappar så att redaktörer kan avfärda varningar. ”Ignorerade” varningar döljs bara för den som klickar; varningar som ”markerats som OK” döljs för alla redaktörer på webbplatsen. Webbplatsadministratörer kan välja vem som har behörighet att göra vad.

Att skapa en kontrollpanel

Ett vanligt klagomål från webbplatsägare var att verktyget gjorde ett utmärkt jobb med att hitta problem över hela webbplatsen, men att det inte fanns något sätt att se en webbplatsövergripande rapport.

Omskrivningen lägger till ett alternativ för att synkronisera resultaten tillbaka till webbplatsens databas. Webbplatsägare kan nu bläddra bland resultaten per sida eller problem och granska vilka problem som har ignorerats eller markerats som OK – och återställa problemet om de inte håller med!

Rundtur i v2-koden för utvecklare

V2 var nästan en fullständig omskrivning. Några av de nya funktionerna:

• Att jQuery-beroendet är borttaget gör att det kan installeras på fler plattformar och ger dubbelt så hög prestanda.
• Granskaren kan nu konfigureras för att söka i flera oberoende delar av sidan (t.ex. artikelinnehållet och sidfoten).
• Granskaren kan nu testa element inuti shadow DOM, som används av olika webbkomponenter och JavaScript-bibliotek.
• Många nya parametrar gör plattformsintegrationer enklare, till exempel att automatiskt ignorera alla problem på vissa sidor för vissa användare, om de inte ansvarar för innehållet på sidan men ändå kan vilja se resultaten vid behov.
• Granskaren levereras nu med flera grundteman och parametrar för att anpassa färger.
• Automatiserad testning hjälper till att förhindra regressioner i koden.

A11yTalks 2024

11 juni 2024

Drupal GovCon 2023

27 oktober 2023

DrupalCamp NJ 2023

28 mars 2023

v1: Infälld hjälp

11 mars 2021

Att skapa webbinnehåll med hög tillgänglighet är komplicerat och börjar oftast med en hel del utbildning.

Invanda vanor måste brytas:

• Tabeller ska inte användas för att skapa låtsaskolumner
• Löpande text ska inte centreras eller marginaljusteras
• Enbart visuell formatering (teckenvikt och storlek) ska inte användas för att förmedla betydelse till användare, som kanske lyssnar på innehållet eller läser det i ”läsläge”

Nya vanor måste uppmuntras:

• Bilder behöver alternativtext som är meningsfull i sitt sammanhang
• Sidor behöver en riktig struktur
• Länkar ska ha meningsfulla titlar

Visst genomförs en del av våra utbildningar för att vi lär ut nya begrepp, men vid någon punkt måste frågan ställas: hur mycket av behovet av nya färdigheter beror på att begreppen är nya, och hur mycket beror på att vi inför nya förväntningar utan att uppdatera våra verktyg? Bara för att något är nytt betyder det inte att det inte kan vara intuitivt.

Lärdomar från stavningens historia

Fas 1: Skyll på författaren

Från den skrivna historiens gryning fram till början av 1980-talet skyllde vi på författaren när ett ord stavades fel. Det var författarens ansvar att lära sig stava rätt.

Hur förbättrade man sin stavning? Det här kommer att låta bekant:

1. Man gick på utbildningar, hos privatlärare eller i klassrum
2. Man fick listor, riktlinjer och ordböcker att studera, ända sedan forntida lexikon i kilskrift ristade i lera.

Fas 2: Skyll på ordboken

Men något förändrades på 1980-talet – låt oss kalla det ”stavningens fas 2”. De populäraste ordbehandlingsprogrammen införde stavningskontroll.

Och vad hände med skuldfrågan? Nästan över en natt flyttades skulden till verktyget:

• Vet du inte hur ett ord stavas? Gissa och hoppas på en träff. Blir det ingen, skyll på ordboken.
• Använder du ett riktigt ord som ordboken flaggar för att den inte känner till det? Muttra lite och bestäm dig för om du ska ignorera understrykningen eller högerklicka och lägga till ordet i ordboken.

Löste stavningskontrollen alla våra stavningsproblem? Absolut inte. Men den hjälpte. Och den flyttade en stor del av bördan och ansvaret från författaren till maskinen.

Men det var inte slutet…

Fas 3: Skyll på redigeringsverktyget

Senare år har fört oss ytterligare ett steg framåt: datorer har börjat stava åt oss:

• Prediktiva algoritmer försöker gissa nästa ord, nästa fras, kanske till och med ett helt svar på ett sms.
• Verktyg för autoformatering försöker omvandla asterisker, siffror och bokstäver till listor, kortkoder till specialtecken och emojier och så vidare.
• Dikteringsverktyg försöker förstå sammanhanget för att välja rätt bland ord som låter lika.

Och vem får skulden när det går snett? Verktyget!

Aggregatorer i sociala medier älskar den pinsamma skärmdumpen av typen ”Det där menade jag inte!”.

Editoria11y är ett steg mot fas 2

På våra utbildningar pratar vi mycket om testning och presenterar flera riktigt bra testverktyg. Inget av dem kan fånga allt: saker som att ”undvika att förklara begrepp genom hänvisningar till färg eller placering” måste kontrolleras av en människa; verktygen fångar vanligtvis knappt hälften av de faktiska problem en webbplats kan ha. Men verktygen är mycket bra på att fånga många vanliga misstag i redaktionellt innehåll.

Men det finns tre problem:

1. De flesta är manuella verktyg. Innehållsskaparen måste ha lärt sig att använda dem, komma ihåg att de finns när innehållet skrivs och komma ihåg att köra dem när det är klart. Dessa tre felkällor samverkar till att mycket (det mesta?) av innehållet förblir okontrollerat.
2. De flaggar för mycket. De markerar inte bara misstag som redaktören just har gjort, utan också färgproblem som designern har skapat, tekniska problem som utvecklaren har skapat, strukturella element i informationssyfte och så vidare. Det höjer ribban för utbildningarna: redaktörer behöver inte bara förstå verktyget, de måste också lära sig att ignorera en lista med falska positiva resultat eller högst verkliga saker som inte är deras ansvar att åtgärda i dag, medan de skriver just den här artikeln.
3. De automatiserade verktygen bygger ofta på modellen ”crawla webbplatsen, besök kontrollpanelen”. Återigen: det förutsätter att redaktören har fått lära sig att besöka kontrollpanelen och kommer ihåg att göra det.

Så Princeton började bygga något nytt: en automatisk granskare, integrerad på webbplatsen, som bara tittar på vanliga redaktionella misstag.

Automatiskt är…knepigt.

1. Automatiska granskare måste vara diskreta: är de för påstridiga avbryter och frustrerar de redaktören. Är de för artiga kan de bli ett bakgrundsbrus som är lätt att ignorera.
2. Automatiska granskare måste ha mycket hög prestanda: om sidan hackar eller tvekar när de körs kommer redaktörerna att störa sig på dem och stänga av dem.
3. Automatiska granskare behöver tips som nybörjare kan förstå. För många redaktörer blir det här första gången de hör talas om den taggning, den struktur och det språk som gör innehållet mer tillgängligt. Varningarna måste vara skrivna på ett enkelt, icke-tekniskt språk, med praktiska råd för att förbättra innehållet.

Så vi började med det verktyg vi kunde hitta som låg närmast dessa mål: Sa11y, från Toronto Metropolitan University. Vi tog dess testarkitektur och dess användarvänliga upplägg med informationspanel och verktygstips, och ägnade ett halvår åt att anpassa verktyget så att testerna alltid kördes automatiskt, optimera prestandan, finslipa verktygstipsen och skapa en lång lista med konfigurationsalternativ som en utvecklare kan använda för att snabbt anpassa det till vilken plattform som helst.

Så här ser det ut i dag:

När en redaktör är inloggad på sin webbplats visar Editoria11y-knappen antalet och typen av problem (godkänt, manuella kontroller behövs, troliga problem hittade) på varje sida. Redaktören kan klicka för att visa markeringar och tips direkt i texten. Om felet är nytt, eftersom sidan just har redigerats, öppnas panelen automatiskt.

Sedan mars 2021 innebär det att mer än 400 av Princetons webbplatser automatiskt kontrollerar följande:

• En bra dokumentstruktur
  • Överhoppade rubriknivåer
  • Tomma rubriker
  • Mycket långa rubriker
  • Misstänkt korta blockcitat som egentligen kan vara rubriker.
• Textalternativ
  • Bilder utan alt-text
  • Bilder med ett filnamn som alt-text
  • Bilder med mycket lång alt-text
  • Alt-text som innehåller överflödig text som ”bild av” eller ”foto av”
  • Bilder i länkar med alt-text som verkar beskriva bilden i stället för länkens mål
  • Inbäddade visualiseringar som oftast kräver ett textalternativ
• Meningsfulla länkar
  • Länkar utan text
  • Länkar som har ett filnamn som titel
  • Länkar som bara har en generisk text som titel: ”klicka här”, ”läs mer”, ”ladda ner” och liknande
  • Länkar som öppnas i ett nytt fönster utan en ikon för extern länk
• Allmän kvalitetssäkring
  • Att se till att listformatering används i stället för asterisker, siffror och bokstäver
  • STORA MÄNGDER TEXT MED VERSALER
  • Tabeller utan rubriker och tabeller med dokumentrubriker (”Rubrik 3”) i stället för tabellrubriker (<th>)
  • Länkar till PDF-filer och andra dokument, med en påminnelse om att testa tillgängligheten hos filen eller erbjuda ett alternativt, tillgängligt format
  • Inbäddade videor, med en påminnelse om att lägga till textning
  • Inbäddat ljud, med en påminnelse om att tillhandahålla ett transkript
  • Inbäddningar från sociala medier, med en påminnelse om att lägga till alt-element

Vi har släppt JavaScript-biblioteket till gemenskapen, skapat en nyckelfärdig Drupal-integration och påbörjat arbetet med en nyckelfärdig WordPress-integration.

Mot fas 3: Tillgängligt som standard

På många sätt är Editoria11y en tillfällig lösning. De flesta misstag det fångar gjordes för att vi ställde nya förväntningar på redaktörer (”tagga ditt innehåll med bra struktur”) men gav dem verktyg som uppmuntrade motsatsen.

Vägen framåt är att göra det enklare, och så automatiskt som möjligt, att skapa tillgängligt innehåll. Hur det ser ut är ännu inte självklart, men det omfattar troligen sådant som:

• Att ompröva vilka alternativ som finns. Till exempel: om vi hela tiden säger åt användare att inte marginaljustera text på webben, är det då dags att pensionera knappen ”marginaljustera text”?
• Att ompröva standardalternativen. Till exempel: standardtabellen i de flesta innehållshanteringssystem har inga rubriker. Det är användaren som måste veta att man ska klicka på ”egenskaper” och lägga till tillgänglighetsfunktioner; kanske är det dags att vända på det?
• Att fundera över prediktiv formatering och ”ledtrådar medan du arbetar”. Om en användare gör en hel rad fetstilt, kan vi då föreslå att den görs till en rubrik? Om en användare ska välja en rubrik, kan vi då gissa vilka rubriknivåer hen kan vilja ha i stället för att erbjuda sex alternativ? Kan vi erbjuda utbildning precis när den behövs för svåra begrepp?