Nyheter

Aktive prosjekter

Sist oppdatert 31. oktober 2026

Pågår

v3: En komplett pakke for kvalitetssikring

27. september 2026

Avduking på DrupalCon Europe 2026

Viktigste nye funksjoner

• Testkjernen er slått sammen med Sa11y. Det nye, felles utviklede regelsettet legger til utviklertester, kontrastkontroll og lesbarhetsvurdering i kjerneregelsettet for innholdstester.
• Støtte for flere språk
• Bygger for egendefinerte kontroller
• Vedlikeholdsverktøy for dashbord
• Et verktøy for gjennomsøking av nettstedet som legger til nye resultater.
• Gjør det mulig for visse tester (er denne PDF-en tilgjengelig?) å avvise varsler for hele nettstedet for visse roller.
• Delt konfigurasjon: rollebasert testing og rapportvisninger, atskilt for utviklere og innholdsforfattere.

Og kanskje aller viktigst for prosjektets fremtid:

• Fikk et stipend for å starte denne støtteorganisasjonen, som skal hjelpe eksisterende brukere og finansiere arbeid med fremtidige prosjektideer.

v2: Avvisninger og rapporter

2. mars 2023

For to år siden introduserte vi tilgjengelighetsverktøyet Editoria11y som et nøkkelferdig nettstedstillegg for Drupal, som gir forfattere automatisk, umiddelbar tilbakemelding og nyttige tips til hvordan de kan forbedre innholdet sitt.

Vi trodde dette ville fylle et tomrom. Alle eksisterende alternativer krevde opplæring og flittig bruk for å være til nytte, og erfaring hadde vist oss at det ikke var noen effektiv måte å angripe problemet på å prøve å lære opp og følge med på tusenvis av innholdsforfattere i en stor organisasjon. For at et program skulle lykkes, var vi overbevist om at det måtte ha en høy grad av automatisering og gi innholdsforfatterne høflig «opplæring akkurat når den trengs» når det oppdaget vanlige feil.

Det virket.

Ved Princeton snudde det i stor grad retningen på kommunikasjonen min. På plattformer der det var installert, gikk vi fra å sende gjentakende e-poster til innholdsforfattere med oppfordring om alt-tekst og bedre lenker eller overskrifter, til å motta spørsmål fra innholdsforfattere om hvordan de kunne forbedre tekstene sine, så de ikke ble flagget så ofte.

Utenfor Princeton var reaksjonen ren begeistring:

Selvstendige tips

Vi brukte en «sammendrag og detaljer»-tilnærming i v1-tipsene: en kort forklaring av problemet og en lenke til flere detaljer.

Dette var en forbedring sammenlignet med verktøy skrevet for utviklere: tipsene var korte og tydelige. Men valget av hvor det skulle lenkes, var alltid et problem. Flere brukere i offentlig sektor og høyere utdanning følte behov for å endre tipsene for å fjerne lenker til Princetons dokumentasjon, noe som ga dem ekstra arbeid. Så vi skrev om standardtipsene slik at de står på egne ben, med eksempler rett i teksten.

Skillet mellom røde varsler (sikre problemer) og gule advarsler (mulige problemer) viste seg å være forvirrende og til tider irriterende.

Så vi gjorde de gule advarslene om til «manuelle kontroller» for å tydeliggjøre hva de betyr, og la til knapper som lar forfattere avvise varsler. «Ignorerte» varsler skjules bare for den som klikker; varsler som er «merket som OK», skjules for alle redaktører på nettstedet. Nettstedsadministratorer kan velge hvem som har tillatelse til hva.

Et dashbord blir til

En vanlig klage fra nettstedseiere var at verktøyet gjorde en utmerket jobb med å finne problemer over hele nettstedet, men at det ikke fantes noen måte å se en rapport for hele nettstedet på.

Omskrivingen legger til et alternativ for å synkronisere funnene tilbake til nettstedets database. Nettstedseiere kan nå bla gjennom funn etter side eller problem, og se hvilke problemer som er ignorert eller merket som OK – og gjenopprette problemet hvis de er uenige!

Kodeomvisning i v2 for utviklere

V2 var nesten en fullstendig omskriving. Noen av de nye funksjonene:

• Når jQuery-avhengigheten er fjernet, kan verktøyet installeres på flere plattformer, og ytelsen blir dobbelt så god.
• Kontrollverktøyet kan nå konfigureres til å se i flere uavhengige deler av siden (f.eks. artikkelinnholdet og sidefoten).
• Kontrollverktøyet kan nå teste elementer inne i shadow DOM, som brukes av ulike webkomponenter og JavaScript-biblioteker.
• Mange nye parametere gjør plattformintegrasjoner enklere, for eksempel automatisk ignorering av alle problemer på bestemte sider for bestemte brukere, hvis de ikke er ansvarlige for innholdet på den siden, men likevel vil kunne se resultatene ved behov.
• Kontrollverktøyet leveres nå med flere grunntemaer og parametere for å tilpasse farger.
• Automatisert testing bidrar til å forhindre regresjoner i koden.

A11yTalks 2024

11. juni 2024

Drupal GovCon 2023

27. oktober 2023

DrupalCamp NJ 2023

28. mars 2023

v1: Innebygd hjelp

11. mars 2021

Å lage innhold på nettet med høy grad av tilgjengelighet er komplisert, og begynner gjerne med mye opplæring.

Innarbeidede vaner må motvirkes:

• Tabeller bør ikke brukes til å lage falske kolonner
• Løpende tekst bør ikke midtstilles eller blokkjusteres
• Rent visuell formatering (skriftvekt og -størrelse) bør ikke være det eneste som formidler mening til brukere, som kanskje hører innholdet eller ser det i «lesemodus»

Nye vaner må fremmes:

• Bilder trenger alternativ tekst som er meningsfull i sammenhengen
• Sider trenger en reell struktur
• Lenker bør ha meningsfulle titler

Noe av opplæringen vår gjennomføres selvfølgelig fordi vi underviser i nye begreper, men på et tidspunkt må spørsmålet stilles: hvor mye av behovet for ny kompetanse kommer av at begrepene er nye, og hvor mye kommer av at vi innfører nye forventninger uten å oppdatere verktøyene våre? At noe er nytt, betyr ikke at det ikke kan være intuitivt.

Lærdom fra rettskrivningens historie

Fase 1: Skyld på forfatteren

Fra den skrevne historiens begynnelse og frem til tidlig på 1980-tallet la vi skylden på forfatteren når et ord ble stavet feil. Det var forfatterens ansvar å lære seg å stave godt.

Hvordan ble man flinkere til å stave? Dette kommer til å høres kjent ut:

1. De gikk på opplæring, hos privatlærere eller i et klasserom
2. De fikk utdelt lister, retningslinjer og ordbøker å studere, en tradisjon som går helt tilbake til eldgamle kileskriftleksikoner risset i leire.

Fase 2: Skyld på ordboken

Men noe endret seg på 1980-tallet: la oss kalle det «stavefase 2». De mest populære tekstbehandlingsprogrammene fikk stavekontroll.

Og hva skjedde med skyldfordelingen? Nesten over natten ble skylden flyttet til verktøyet:

• Vet du ikke hvordan et ord staves? Gjett og håp på treff. Hvis ikke, skyld på ordboken.
• Bruker du et ekte ord som ordboken flagger fordi den ikke kjenner det? Knurr litt og bestem deg for om du skal ignorere understrekingen eller høyreklikke og legge ordet til i ordboken.

Løste stavekontrollen alle staveproblemene våre? Absolutt ikke. Men den hjalp. Og den flyttet mye av byrden og ansvaret fra forfatteren til maskinen.

Men det var ikke slutten…

Fase 3: Skyld på redigeringsverktøyet

De siste årene har gitt oss enda et skritt fremover: datamaskiner har begynt å stave for oss:

• Prediktive algoritmer prøver å gjette neste ord, neste frase, kanskje til og med et helt svar på en tekstmelding.
• Autoformateringsverktøy prøver å gjøre stjerner, tall og bokstaver om til lister, gjøre kortkoder om til spesialtegn og emoji osv.
• Dikteringsverktøy prøver å forstå sammenhengen for å velge mellom homonymer.

Og hvem får skylden når dette går galt? Verktøyet!

Samlesider i sosiale medier elsker de pinlige «Det var ikke det jeg mente!»-skjermbildene.

Editoria11y er et skritt mot fase 2

I opplæringen vår snakker vi mye om testing og introduserer flere ganske gode testverktøy. Ingen av dem fanger opp alt: slikt som å «unngå å forklare begreper gjennom farge- eller romlige referanser» må kontrolleres av et menneske; verktøy fanger vanligvis opp litt under halvparten av de faktiske problemene et nettsted kan ha. Men verktøyene er svært gode til å fange opp mange vanlige feil i redaksjonelt innhold.

Men det er tre problemer:

1. De fleste er manuelle verktøy. Innholdsforfatteren må ha lært å bruke dem, må huske at de finnes når innholdet skrives, og må huske å kjøre dem når det er ferdig. Disse tre svakhetene bidrar til sammen til at mye (mesteparten?) av innholdet aldri blir kontrollert.
2. De flagger for mye. De markerer ikke bare feil forfatteren nettopp har gjort, men også fargeproblemer fra designeren, tekniske problemer fra utvikleren, strukturelle elementer til informasjon osv. Dette hever terskelen for opplæringen: forfattere må ikke bare forstå verktøyet, de må også læres opp til å ignorere en liste over falske positiver eller helt reelle ting som det ikke er deres ansvar å rette i dag, mens de skriver akkurat denne artikkelen.
3. De automatiserte verktøyene følger gjerne et paradigme der man gjennomsøker nettstedet og deretter besøker dashbordet. Igjen: dette forutsetter at forfatteren har lært å besøke dashbordet og husker å gjøre det.

Så Princeton satte seg fore å lage noe nytt: et automatisk kontrollverktøy integrert i nettstedet, som bare ser etter vanlige redaksjonelle feil.

Automatisk er… krevende.

1. Automatiske kontrollverktøy må være diskrete: er de for påtrengende, avbryter og frustrerer de forfatteren. Er de for høflige, kan de fort bli bakgrunnsstøy som er lett å overse.
2. Automatiske kontrollverktøy må ha svært god ytelse: hvis siden hakker eller nøler mens de kjører, vil forfatterne mislike dem og slå dem av.
3. Automatiske kontrollverktøy trenger tips som passer for nybegynnere. For mange forfattere vil dette være første gang de hører om merkingen, strukturen og språket som gjør innholdet deres mer tilgjengelig. Varsler må skrives på enkelt, ikke-teknisk språk, med praktiske råd om hvordan innholdet kan forbedres.

Så vi begynte med det verktøyet vi fant som kom nærmest disse målene: Sa11y, fra Toronto Metropolitan University. Vi tok testarkitekturen og den brukervennlige tilnærmingen med informasjonspanel og verktøytips, og brukte et halvt år på å tilpasse verktøyet slik at testene alltid kjørte automatisk, optimalisere ytelsen, finjustere verktøytipsene og lage en lang liste med konfigurasjonsvalg som en utvikler kunne bruke til raskt å tilpasse det til en hvilken som helst plattform.

Slik ser det ut i dag:

Når en forfatter er logget inn på nettstedet sitt, viser Editoria11y-bryteren antall og type problemer (bestått, manuelle kontroller nødvendig, sannsynlige problemer funnet) på hver side. Forfatteren kan klikke for å vise markering og tips direkte i innholdet. Hvis feilen er ny, fordi forfatteren ser på en side som nettopp er redigert, åpnes panelet automatisk.

Per mars 2021 betyr dette at mer enn 400 nettsteder ved Princeton automatisk ser etter:

• En god dokumentstruktur
  • Overhoppede overskriftsnivåer
  • Tomme overskrifter
  • Svært lange overskrifter
  • Mistenkelig korte blokksitater som egentlig kan være overskrifter.
• Tekstalternativer
  • Bilder uten alt-tekst
  • Bilder med et filnavn som alt-tekst
  • Bilder med svært lang alt-tekst
  • Alt-tekst med overflødig tekst som «bilde av» eller «foto av»
  • Bilder i lenker med alt-tekst som ser ut til å beskrive bildet i stedet for lenkemålet
  • Innebygde visualiseringer som vanligvis krever et tekstalternativ
• Meningsfulle lenker
  • Lenker uten tekst
  • Lenker med et filnavn som tittel
  • Lenker som bare har generisk tekst som tittel: «klikk her», «les mer», «last ned» osv.
  • Lenker som åpnes i et nytt vindu uten ikon for ekstern lenke
• Generell kvalitetssikring
  • At listeformatering brukes i stedet for stjerner, tall og bokstaver
  • STORE MENGDER TEKST MED CAPS LOCK
  • Tabeller uten overskrifter og tabeller med dokumentoverskrifter («Overskrift 3») i stedet for tabelloverskrifter (<th>)
  • Lenker til PDF-er og andre dokumenter, med påminnelse om å teste nedlastingen for tilgjengelighet eller tilby et alternativt, tilgjengelig format
  • Innebygde videoer, med påminnelse om å legge til undertekster
  • Innebygd lyd, med påminnelse om å tilby en transkripsjon
  • Innebygd innhold fra sosiale medier, med påminnelse om å legge til alt-elementer

Vi har gjort JavaScript-biblioteket tilgjengelig for fellesskapet, laget en nøkkelferdig Drupal-integrasjon og begynt arbeidet med en nøkkelferdig WordPress-integrasjon.

Mot fase 3: Tilgjengelig som standard

På mange måter er Editoria11y en midlertidig løsning. De fleste feilene det fanger opp, ble gjort fordi vi stilte nye forventninger til innholdsforfattere («merk innholdet med god struktur»), men ga dem verktøy som oppmuntret til det motsatte.

Veien videre er å gjøre det enklere og så automatisk som mulig å lage tilgjengelig innhold. Hvordan det vil se ut, er ennå ikke klart, men det omfatter sannsynligvis ting som:

• Å tenke nytt om hvilke valg som er tilgjengelige. For eksempel: Hvis vi stadig sier til brukerne at de ikke skal blokkjustere tekst på nettet, er det kanskje på tide å pensjonere «blokkjuster tekst»-knappen?
• Å tenke nytt om standardvalgene. For eksempel: Standardtabellen i de fleste innholdsstyringssystemer har ikke overskrifter. Det er opp til brukeren å vite at man må klikke på «egenskaper» og legge til tilgjengelighetsfunksjoner; kanskje det er på tide å snu dette?
• Å utforske prediktiv formatering og «hint mens du jobber». Hvis en bruker gjør en hel linje fet, kan vi foreslå å gjøre den til en overskrift? Hvis en bruker skal velge en overskrift, kan vi gjette hvilke overskriftsnivåer vedkommende vil ha, i stedet for å gi seks valg? Kan vi gi opplæring akkurat når den trengs for vanskelige begreper?