Om du har sökt efter webbtillgänglighetslösningar har du sannolikt stött på verktyg som lovar att göra din webbplats kompatibel med WCAG-standarder omedelbart. Lägg bara till en kodrad, hävdar de, och dina tillgänglighetsproblem försvinner. Det här är tillgänglighetsoverlays, och de har blivit ett av de mest kontroversiella ämnena i tillgänglighetssamhället. Men här är vad som ofta blir förväxlat: inte alla tillgänglighetsverktyg är overlays. Tillgänglighetswidgets tjänar ett helt annat syfte. Att förstå skillnaden är inte bara akademiskt. Det påverkar dina användare, ditt juridiska ansvar och huruvida dina tillgänglighetsinsatser faktiskt hjälper personer med funktionsnedsättningar eller bara skapar en illusion av efterlevnad. Denna artikel bryter ner vad overlays och widgets faktiskt är, varför den ena är allmänt kritiserad medan den andra kan vara legitimt hjälpsam, och vilket tillvägagångssätt som faktiskt fungerar för att skapa tillgängliga webbplatser.
Vad är tillgänglighetsoverlays?
Tillgänglighetsoverlays är tredjepartslösningar som påstår sig automatiskt upptäcka och åtgärda tillgänglighetsproblem på din webbplats. Företag som AccessiBe, UserWay och AudioEye erbjuder dessa produkter, vanligtvis som prenumerationstjänster som injicerar JavaScript på din webbplats.
Erbjudandet är tilltalande: lägg till en enda kodrad på din webbplats, och AI-driven reparation kommer att hantera alla dina tillgänglighetsproblem. Overlayen skannar dina sidor, identifierar problem som saknad alt-text eller färgkontrastproblem och påstår sig fixa dem i farten utan att kräva att du ändrar din faktiska kod.
De flesta overlays inkluderar också en synlig widget på din webbplats, vanligtvis visad som en flytande ikon. Användare kan klicka på denna ikon för att komma åt funktioner som textstorleksändring, färgjusteringar eller innehållsförenkling. Overlay-leverantören hanterar allt och lovar WCAG 2.1 AA eller till och med AAA-efterlevnad med minimal ansträngning från dig.
Det låter perfekt. Så varför kallar tillgänglighetsförespråkare overlays för skadliga?
Overlay-kontroversen: Varför tillgänglighetsexperter motsätter sig
Tillgänglighetssamhällets invändningar mot overlays handlar inte om mindre tekniska detaljer. Det handlar om grundläggande effektivitet och, i vissa fall, att göra tillgängligheten sämre.
#OverlayFalseAlarm-rörelsen, lanserad av tillgänglighetsförespråkare, har dokumenterat hur overlays misslyckas med att uppfylla sina löften. Här är kärnproblemet: tillgänglighet är inte något du kan eftermontera enbart genom JavaScript. Det kräver korrekt semantisk HTML, korrekta ARIA-attribut, tangentbordsnavigeringsdesign och innehållsstrukturbeslut som måste fattas under utvecklingen.
När en overlay försöker injicera tillgänglighetsfunktioner i efterhand gör den utbildade gissningar om ditt innehålls betydelse och struktur. Dessa gissningar är ofta felaktiga. En overlay kan lägga till alt-text till en bild baserat på filnamnsanalys, men om det filnamnet är 'IMG_3847.jpg' är den genererade beskrivningen värdelös. Den kan lägga till ARIA-etiketter till knappar, men om dessa etiketter motsäger den faktiska knappfunktionen får skärmläsaranvändare förvirrande eller missvisande information.
Mer oroande är att overlays ofta stör hjälpmedel. Skärmläsare som JAWS och NVDA är sofistikerade verktyg som användare lär sig navigera effektivt. När en overlay modifierar sidstruktur eller injicerar ytterligare navigationslager kan det bryta det förväntade beteendet. Användare som har spenderat år på att bemästra sin hjälpmedelsteknik finner plötsligt bekanta webbplatser beter sig oförutsägbart.
Vad overlays påstår vs vad de faktiskt gör
Låt oss undersöka specifika påståenden som overlay-leverantörer gör och vad som faktiskt händer i praktiken.
Påstående: 'Uppnå WCAG 2.1 AA-efterlevnad automatiskt.' Verklighet: WCAG-efterlevnad kräver mänskligt omdöme på många områden. Framgångskriterium 1.1.1 (icke-textinnehåll) kräver att bilder har textalternativ som tjänar motsvarande syfte. Ingen AI kan bestämma syfte utan att förstå ditt innehålls sammanhang. Ett foto kan behöva detaljerad beskrivning, kan vara rent dekorativt eller funktionellt. Detta är redaktionella beslut, inte tekniska.
Påstående: 'Åtgärda färgkontrastproblem.' Verklighet: Overlays kan upptäcka kontrastförhållanden, men att fixa dem ordentligt kräver designbeslut. Ska låg kontrast text bli mörkare, eller ska bakgrunden ändras? Hur påverkar dessa ändringar din varumärkesidentitet? Overlays tillämpar vanligtvis tunna filter som gör text läsbar men visuellt skärande, vilket ofta bryter noggrant designade layouter.
Påstående: 'Tillhandahåll tangentbordsnavigering.' Verklighet: Korrekt tangentbordsnavigering kräver logisk tabbordning, synliga fokusindikatorer och tangentbordsgenvägar som inte kolliderar med webbläsare eller hjälpmedelskommandon. Overlays kan lägga till tabbindex, men de kan inte omstrukturera ologiska HTML-hierarkier eller designa förnuftiga tangentbordsgenvägar för komplexa gränssnitt.
Påstående: 'Vår AI skannar din webbplats kontinuerligt.' Verklighet: Overlays skannar DOM (Document Object Model) för renderade sidor. De kan inte se dynamiskt innehåll som laddas genom JavaScript-ramverk förrän det renderas, och de kämpar med ensidesapplikationer där innehåll ändras utan siduppdateringar. De kan inte heller komma åt autentiseringskrävande sidor i många fall, vilket lämnar medlemsområden eller kassakrocesser oadresserade.
Den juridiska verkligheten: Overlays skyddar dig inte från stämningar
Kanske den viktigaste frågan för företag: skyddar en overlay dig från juridiskt ansvar enligt ADA eller liknande regler?
Svaret, baserat på faktisk rättspraxis, är nej.
Talrika tillgänglighetsstämningar har fortsatt mot företag som använder overlay-produkter. Faktum är att närvaron av en overlay ibland fungerar emot svarandena. Målsägandens advokater argumenterar för att installation av en overlay bevisar att företaget var medvetet om tillgänglighetsproblem men valde en ineffektiv lösning snarare än korrekt reparation.
Advokatbyrån Lainey Feingold, en framstående handikappträttighetsadvokat, har uttalat tydligt: 'Overlays ger inte personer med funktionsnedsättningar lika tillgång till webbplatser.' Domstolar har konsekvent beslutat att webbplatser måste vara tillgängliga i sin ursprungliga form, inte genom valfria modifieringar som användare måste upptäcka och aktivera.
Betänk användarupplevelsen: en blind person kommer till din webbplats med en skärmläsare. Din webbplats har navigeringsproblem, saknade formuläretiketter och oklar rubrikstruktur. En overlay-widget visas på skärmen, men skärmläsaranvändaren kan inte lätt hitta den bland de trasiga navigationselementen. Även om de hittar den och aktiverar den kanske overlayens modifieringar inte åtgärdar de grundläggande strukturella problemen.
Ur ett efterlevnadsperspektiv kräver ADA Titel III och Sektion 508 lika tillgång, inte separat tillgång genom specialiserade verktyg. Overlays skapar i sig en separat upplevelse.
Vad tillgänglighetswidgets faktiskt är
Låt oss nu skilja widgets från overlays. Termerna blandas ofta ihop, men de representerar fundamentalt olika tillvägagångssätt.
En tillgänglighetswidget är ett användarvänt verktyg som låter besökare anpassa sin visningsupplevelse. Den påstår sig inte fixa tillgänglighetsproblem i din kod. Istället tillhandahåller den preferenskontroller för användare som drar nytta av alternativa presentationer.
Typiska widget-funktioner inkluderar textstorleksjustering, radhöjd och avståndskontroller, kontrastlägesväxlingar, teckensnittsändringar för läsbarhet, läsguider eller masker samt markering av länkar eller rubriker. Vissa widgets erbjuder översättning, innehållsförenkling eller text-till-tal för användare som föredrar auditivt innehåll.
Den kritiska skillnaden: en legitim widget påstår sig inte göra en otillgänglig webbplats tillgänglig. Den förbättrar en redan tillgänglig webbplats för användare med specifika preferenser. Tänk på det som tillgänglighetsfunktioner i operativsystem. Windows Magnifier fixar inte dåligt designad programvara, men den hjälper användare med nedsatt syn att använda väldesignade applikationer mer bekvämt.
Widgets respekterar användarens autonomi. De tvingar inte ändringar på användare eller antar att de vet bättre än hjälpmedel. De tillhandahåller alternativ som användare kan aktivera om de vill, utan att störa skärmläsare, tangentbordsnavigering eller andra hjälpmedel.
Viktiga skillnader: Widget vs overlay
Låt oss göra skillnaden konkret med direkta jämförelser.
Syfte: Overlays påstår sig automatiskt åtgärda tillgänglighetsproblem. Widgets tillhandahåller valfria användarpreferenser för visningskomfort.
Implementering: Overlays injicerar kod som modifierar din webbplats struktur och innehåll. Widgets tillämpar CSS- och JavaScript-förbättringar utan att ändra underliggande HTML.
Marknadsföringspåståenden: Overlays lovar WCAG-efterlevnad och juridiskt skydd. Widgets erbjuder anpassningsalternativ för att förbättra användarupplevelsen.
Interaktion med hjälpmedel: Overlays stör ofta skärmläsare och andra verktyg. Widgets fungerar tillsammans med hjälpmedel utan konflikt.
Användarkontroll: Overlays antar att de vet vad användare behöver och tillämpar ändringar automatiskt. Widgets låter användare välja vilka funktioner som ska aktiveras.
Juridisk ställning: Overlays skyddar inte mot ADA-stämningar. Widgets gör inga efterlevnadspåståenden och påverkar inte juridisk status.
Målanvändare: Overlays riktar sig till webbplatsägare som söker enkel efterlevnad. Widgets riktar sig till slutanvändare som vill ha visningsanpassning.
Tekniskt tillvägagångssätt: Overlays försöker fixa trasig tillgänglighet genom JavaScript-lappar. Widgets förbättrar korrekt kodad tillgänglighet med användarpreferenser.
Problemet med automatisk reparation
Att förstå varför overlays misslyckas kräver att man förstår vad tillgänglighet faktiskt betyder.
Tillgänglighet är inte främst ett tekniskt problem. Det är ett design- och innehållsproblem som har tekniska implementeringar. WCAG-riktlinjerna finns eftersom vissa designmönster utesluter personer med funktionsnedsättningar. Att uppfylla dessa riktlinjer kräver avsiktliga val om innehållsstruktur, interaktionsdesign och informationsarkitektur.
Betänk formulärdesign. Ett tillgängligt formulär behöver korrekt associerade etiketter, tydliga felmeddelanden, logisk gruppering av relaterade fält och instruktioner som fungerar utan visuell formatering. En overlay kan inte skapa dessa element. Den kan lägga till ARIA-attribut, men ARIA är tänkt att förbättra korrekt strukturerad HTML, inte ersätta den. W3C:s första ARIA-regel är: 'Om du kan använda ett inbyggt HTML-element eller attribut med semantiken och beteendet du redan kräver, istället för att ombilda ett element och lägga till en ARIA-roll, tillstånd eller egenskap för att göra det tillgängligt, gör då det.'
Overlays bryter systematiskt mot denna princip. De tillämpar ARIA som en lapp för dålig HTML snarare än att använda ARIA för att förbättra bra HTML. Resultatet är ett ömtåligt, motsägelsefullt semantiskt lager som förvirrar hjälpmedel.
Automatisering har sin plats i tillgänglighet. Automatiserade testverktyg kan upptäcka många tekniska problem effektivt. Men upptäckt är inte reparation. Ett verktyg kan flagga saknad alt-text, men bara en människa kan skriva meningsfull alternativ text. Ett verktyg kan mäta färgkontrast, men bara en designer kan skapa lösningar som uppfyller kontrastkrav samtidigt som de bibehåller visuell attraktion.
När är en tillgänglighetswidget meningsfull?
Trots problemen med overlays finns det legitima användningsfall för tillgänglighetswidgets när de distribueras korrekt.
Widgets är meningsfulla som användbarhetförbättringar på webbplatser som redan är tillgängliga. Om din webbplats uppfyller WCAG 2.1 AA-standarder genom korrekt kodning kan en widget tillhandahålla ytterligare komfortfunktioner som går utöver minimikrav. Användare som inte använder hjälpmedel på heltid men har specifika preferenser kan dra nytta av snabb åtkomst till textstorlekskontroller eller kontrastlägen.
Utbildningssammanhang erbjuder ett annat giltigt användningsfall. En universitetsbibliotekswebbplats kan erbjuda en widget med funktioner som dyslexivänliga teckensnitt, radavståndsjusteringar och läsguider. Dessa funktioner kompletterar korrekt strukturerat, tillgängligt innehåll genom att tillhandahålla specialiserade visningslägen för användare med specifika inlärningsskillnader.
Widgets kan också tjäna användare i situationella funktionsnedsättningssammanhang. Någon som använder en mobil enhet i starkt solljus kan tillfälligt aktivera högkontrastläge. En användare i ett tyst bibliotek kan föredra text-till-tal istället för video med textning. Dessa situationella behov skiljer sig från permanenta funktionsnedsättningar men representerar legitima tillgänglighetsöverväganden.
Nyckelprincipen: widgets förbättrar, de ersätter inte. De är glasyr på en redan bakad kaka, inte en ersättning för bakning. Om du överväger en widget, se först till att din webbplats fungerar ordentligt med skärmläsare, tangentbordsnavigering och andra hjälpmedel. Sedan kan en widget erbjuda valfria förbättringar.
Vad som faktiskt fungerar: Rätt tillvägagångssätt för webbtillgänglighet
Om overlays inte fungerar och widgets ensamma inte räcker, vad är det korrekta tillvägagångssättet?
Verklig tillgänglighet börjar i designfasen. När du planerar en webbplats, överväg tillgänglighet från början. Välj färgpaletter med tillräcklig kontrast. Designa tangentbordsnavigationsmönster innan du implementerar musinteraktioner. Planera innehållshierarki som fungerar som både en visuell layout och en logisk struktur för skärmläsare.
Under utvecklingen, använd semantisk HTML. Rubriker bör använda rubriktaggar i logisk ordning, inte stiliserade div-taggar. Knappar bör vara knappelement, inte klickbara spans. Formulär bör använda etiketter som är korrekt associerade med inputs. Detta är inte valfria bästa praxis; de är grundläggande krav för tillgänglighet.
Testning måste inkludera verkliga hjälpmedel. Installera NVDA eller använd VoiceOver på Mac. Navigera din webbplats med endast tangentbord. Använd webbläsartillägg som WAVE eller Axe för att fånga tekniska problem. Men kom ihåg: automatiserade verktyg fångar endast cirka 30-40% av tillgänglighetsproblemen. Manuell testning är nödvändig.
Löpande underhåll spelar roll eftersom webbplatser förändras. Innehållsuppdateringar, nya funktioner och designuppfrischningar kan introducera tillgänglighetsproblem. Regelbundna revisioner och testning bör vara en del av din utvecklingscykel, inte engångshändelser.
I detta sammanhang kan en korrekt designad widget passa som en användbarhetförbättring. Men den kommer sist, efter korrekt kodning, grundlig testning och dokumenterade tillgänglighetspolicyer. Det är ett körsbär på toppen, inte grunden.
Hur man utvärderar tillgänglighetsverktyg
Om du letar efter tillgänglighetsverktyg, hur skiljer du hjälpsamma widgets från problematiska overlays?
För det första, var försiktig med efterlevnadslöften. Alla verktyg som påstår sig göra din webbplats WCAG-kompatibel automatiskt gör ett omöjligt löfte. Efterlevnad kräver mänskligt omdöme och korrekt kodning, inte JavaScript-injektion.
För det andra, leta efter transparens om begränsningar. Legitima verktyg erkänner vad de inte kan göra. Om en leverantör påstår att deras AI kan fixa alla tillgänglighetsproblem är de antingen oinformerade eller oärliga. Båda är röda flaggor.
För det tredje, kontrollera kompatibilitet med hjälpmedel. En bra widget bör ha dokumentation om skärmläsarkompatibilitet och tangentbordsnavigering. Den bör ha testats med verkliga hjälpmedel, inte bara automatiserade verktyg.
För det fjärde, undersök användarupplevelsen. Installera verktyget på en testwebbplats och navigera med en skärmläsare. Hjälper det eller stör det? Är widgetens funktioner upptäckbara utan syn? Respekterar den användarpreferenser som redan ställts in genom hjälpmedel?
För det femte, undersök juridiska påståenden noggrant. Vissa overlay-leverantörer framhäver låga stämningsnivåer bland sina kunder. Detta är missvisande. Många tillgänglighetsstämningar tar år att lösa, och företag löser ofta konfidentiellt. Frånvaron av offentliga stämningar bevisar inte effektivitet.
Slutligen, konsultera funktionshindersamhället. Organisationer som National Federation of the Blind har publicerat ståndpunkter om overlays. Enskilda förespråkare bloggar om sina erfarenheter. Lyssna på de människor dessa verktyg påstår sig hjälpa.
Kostnaden för att göra fel
Insatserna för tillgänglighet sträcker sig bortom juridisk efterlevnad, även om de juridiska riskerna är verkliga och växande.
Ur ett affärsperspektiv utesluter otillgängliga webbplatser kunder. CDC uppskattar att 26% av amerikanska vuxna har någon typ av funktionsnedsättning. Det är inte en nischmarknad; det är en fjärdedel av din potentiella publik. En otillgänglig kassakprocess riskerar inte bara stämningar, den förlorar försäljning.
Rykte spelar också roll. Funktionshindersamhällen är sammankopplade och högljudda. En webbplats som distribuerar en overlay möter ofta kritik på sociala medier och tillgänglighetsforum. #overlayfalseAlarm-hashtaggen dokumenterar dessa reaktioner. Företag som lyssnar och gör korrekta ändringar bygger goodwill. De som försvarar overlays skadar sitt varumärke med funktionshindersamhällen.
SEO-implikationer finns också. Många bästa tillgänglighetspraxis överlappar med SEO-bästa praxis. Korrekt rubrikhierarki hjälper skärmläsare och sökmotorer. Meningsfull länktext förbättrar både tangentbordsnavigering och klickfrekvenser. Alternativ text för bilder gynnar både blinda användare och bildsökningsrankningar. Otillgängliga webbplatser rankas ofta dåligt.
Slutligen finns det den etiska dimensionen. Att bygga otillgängliga webbplatser 2026 är att välja att utesluta personer med funktionsnedsättningar från digitala utrymmen som alltmer dominerar det moderna livet. Bank, shopping, myndighetstjänster, utbildning och social kontakt sker alla online. Tillgänglighet är inte en tjänst; det är en medborgerlig rättighet.
Framåt: Praktiska nästa steg
Om du har förlitat dig på en overlay, vad ska du göra nu?
För det första, få inte panik och ta inte bort overlayen omedelbart utan en plan. Det kan göra saker värre om användare har anpassat sig till den. Istället, skapa en övergångsplan.
Börja med en tillgänglighetsrevision. Anlita en kvalificerad konsult eller använd en kombination av automatiserad testning och manuell granskning för att identifiera aktuella problem. Prioritera problem som blockerar kärnfunktionalitet som navigering, formulär och kritiskt innehåll.
Utveckla en reparationsfärdplan. Vissa fixar är snabba: lägga till alt-text, fixa färgkontrast, säkerställa tangentbordsåtkomst. Andra kräver designändringar: omstrukturering av navigering, omdesign av formulär, skapande av innehållshierarkier. Planera realistiska tidslinjer och tilldela resurser.
Om du vill behålla en widget för användarpreferenser, undersök alternativ till overlay-produkter. Leta efter verktyg som inte gör några efterlevnadspåståenden och fokuserar på användaranpassning. Testa dessa verktyg grundligt med hjälpmedel innan distribution.
Kommunicera förändringar till användare. Om du tar bort en overlay som användare har förlitat sig på, ge meddelande och förklara att du istället implementerar korrekta tillgänglighetsfunktioner. Om du lägger till en widget som ett preferensverktyg, klargör att det är ett alternativ, inte nödvändigt för tillgänglighet.
Dokumentera dina tillgänglighetspolicyer och procedurer. Skapa en tillgänglighetsförklaring som förklarar ditt engagemang, nuvarande efterlevnadsnivå och hur användare kan rapportera problem. Utse någon ansvarig för tillgänglighet i din organisation.
Viktigast av allt, förbind dig till pågående tillgänglighet. Det är inte ett projekt med ett slutdatum. När din webbplats utvecklas måste tillgänglighet vara en del av varje förändring.
Rollen för testverktyg vs reparationsverktyg
Att förstå skillnaden mellan testning och reparation hjälper till att klargöra var verktyg passar i tillgänglighetsarbetet.
Testverktyg identifierar problem. Produkter som vår Web Accessibility Checker skannar din webbplats, flaggar WCAG-överträdelser och tillhandahåller rapporter som detaljerar problem. Dessa verktyg är värdefulla eftersom de fångar många tekniska problem snabbt. De kan kontrollera hundratals sidor för saknad alt-text, färgkontrastproblem eller formuläretikettproblem på några minuter.
Men testverktyg fixar inte problem. De berättar vad som är fel och föreslår ofta lösningar, men människor måste implementera dessa lösningar i den faktiska kodbasen. Detta är lämpligt eftersom att fixa tillgänglighetsproblem kräver sammanhang och omdöme.
Reparationsverktyg påstår sig fixa problem automatiskt. Det är här overlays misslyckas. Komplexiteten i webbtillgänglighet innebär att automatiserade fixar ofta är otillräckliga eller kontraproduktiva. En overlay kan lägga till en generisk alt-text baserad på bildanalys, men den generiska beskrivningen uppfyller inte WCAG-kraven om den inte förmedlar bildens syfte i sammanhanget.
Det effektiva tillvägagångssättet använder testverktyg för att identifiera problem, sedan manuell reparation för att fixa dem ordentligt. Efter att fixar har implementerats verifierar testverktyg att problemen är lösta. Denna cykel av test, fix, verifiera och omtest är hur professionellt tillgänglighetsarbete sker.
Widgets passar inte i detta test/reparations-arbetsflöde. De är användarriktade funktioner, inte utvecklingsverktyg. En widget som låter användare justera textstorlek testar eller fixar inte något; den tillhandahåller anpassning. Det är därför widgets och testverktyg kan samexistera på lämpligt sätt, medan overlays som lovar automatisk reparation skapar problem.
Att bygga in tillgänglighet i din utvecklingsprocess
Långsiktig tillgänglighetsframgång kräver att det integreras i hur du bygger och underhåller webbplatser.
Börja med utvecklarutbildning. Många tillgänglighetsproblem härrör från att utvecklare inte vet bättre, inte från avsiktligt uteslutande. Att utbilda utvecklare i semantisk HTML, ARIA-användning och hjälpmedelstestning ger löpande utdelning. Betrakta det som en investering som vilken annan teknisk kompetensutveckling som helst.
Inkorporera tillgänglighet i designgranskningar. Innan implementering börjar, granska mockups och prototyper för potentiella tillgänglighetsproblem. Kan interaktiva element nås med tangentbord? Är färgkombinationer tillräckliga för kontrast? Är innehållshierarkin tydlig utan visuell formatering? Att fånga problem i designstadiet är mycket billigare än att fixa dem efter implementering.
Använd automatiserad testning i din utvecklingspipeline. Verktyg som Pa11y, Axe eller Lighthouse kan köras under kontinuerlig integration och fånga regressioner innan kod når produktion. Konfigurera dessa verktyg för att misslyckas med byggen när kritiska tillgänglighetsproblem upptäcks, precis som du skulle göra för trasig funktionalitet.
Genomför användartester med personer som har funktionsnedsättningar. Ingen mängd automatiserad testning ersätter verkliga användare. Om möjligt, inkludera personer med funktionsnedsättningar i din användarforskning. Om budgetbegränsningar förhindrar formell testning, överväg att delta i tillgänglighetsfeedbackprogram eller anlita konsulter som själva är funktionshindrade.
Skapa ansvarighetsstrukturer. Tilldela tillgänglighetsansvar tydligt. Oavsett om det är en dedikerad tillgänglighetsspecialist, en utvecklingsteamledare eller delat ansvar med definierat ägande måste någon förespråka tillgänglighet och ha befogenhet att prioritera det.
Med dessa processer på plats blir tillgänglighet en del av kvalitetssäkring snarare än en eftertanke eller ett snabbfixförsök genom overlays.