WCAG 1.4.7: Låg eller ingen bakgrundsljud

Vad den här regeln innebär

WCAG framgångskriterium 1.4.7 — Låg eller ingen bakgrundsljudnivå — gäller för förinspelat ljudinnehåll utan bild som innehåller tal i förgrunden. Det gäller inte för ljud som i sig är en musikalisk framförelse, till exempel en sång, eller för ljud som främst är en ambient ljudbild utan avsedd talkomponent. När talbaserat ljudinnehåll finns, kräver kriteriet att minst ett av följande tre villkor uppfylls:

• Inget bakgrundsljud: Ljudspåret innehåller tal utan några bakgrundsljud alls — tystnad bakom rösten.
• Användarkontroll: Eventuellt bakgrundsljud kan stängas av av användaren, oberoende av talet i förgrunden, utan att påverka talinnehållet.
• 20 dB-regeln: Bakgrundsljud är minst 20 decibel lägre i volym än talet i förgrunden. En skillnad på 20 dB motsvarar ungefär att bakgrundsljudet är fyra gånger tystare än talet, vilket är en betydelsefull upplevd skillnad för de flesta lyssnare.

Ett godkänt resultat registreras när något av dessa tre villkor är helt uppfyllt. Ett underkänt resultat uppstår när tal i förgrunden konkurrerar med bakgrundsljud som inte kan stängas av och vars volymskillnad är mindre än 20 dB i förhållande till talsignalen. Observera att tillfälliga ljudeffekter — såsom en kort notifieringssignal — som varar endast en eller två sekunder uttryckligen undantas från detta krav i WCAG-specifikationen.

Detta kriterium gäller för ljudspåret oavsett om ljudet levereras som en fristående ljudfil, som ljudkomponenten i en video, eller inbäddat via en podcastspelare, HTML5-<audio>-element eller en tredjeparts mediakomponent. Kravet handlar om produktionen av själva ljudinnehållet, inte om ett specifikt HTML-element eller en ARIA-attribut — vilket är anledningen till att automatiska skanningsverktyg inte pålitligt kan upptäcka överträdelser och manuell granskning av det faktiska ljudinnehållet alltid är nödvändig.

Varför det är viktigt

Enligt Världshälsoorganisationen lever cirka 1,5 miljarder människor världen över med någon grad av hörselnedsättning. Även måttlig hörselnedsättning kan göra det extremt svårt — ibland omöjligt — att urskilja en talares röst när bakgrundsmusik, omgivningsljud eller andra ljudelement är mixade på liknande eller konkurrerande volymnivåer. För användare som är beroende av hörapparater eller cochleaimplantat förstärks bakgrundsljudstörningar tillsammans med talet, vilket gör begripligheten dramatiskt sämre snarare än bättre.

Användare med kognitiva funktionsnedsättningar, inklusive personer med uppmärksamhetsstörningar, auditiva perceptionsstörningar eller traumatiska hjärnskador, möter också betydande utmaningar när ljudspår innehåller konkurrerande ljud. Även när lyssnaren inte har någon mätbar hörselnedsättning kan hjärnan ha svårt att filtrera bort irrelevanta ljudsignaler och fokusera på talinnehållet, vilket leder till trötthet, bristande förståelse eller fullständig utestängning från innehållet.

Överväg ett konkret scenario i verkligheten: en turkisk myndighet publicerar en inspelad ljudförklaring om hur medborgare kan ansöka om en social förmån. Berättarrösten är mixad över ett kontinuerligt bakgrundsmusikspår på ungefär samma volymnivå. En användare med måttlig sensorineural hörselnedsättning besöker sidan med en hörapparat. Eftersom hörapparaten förstärker alla frekvenser samtidigt konkurrerar musiken direkt med berättarens tal. Användaren kan inte förstå instruktionerna och missar en tidsfrist för sin förmånsansökan. Om ljudet hade spelats in utan bakgrundsmusik, eller om en volymkontroll hade tillhandahållits för att dämpa bakgrundsspåret oberoende, skulle användaren ha haft likvärdig tillgång till informationen.

Utöver funktionsnedsättning förbättrar tydligt ljud med minimalt bakgrundsbrus förståelsen för alla användare — de som lyssnar i bullriga miljöer på mobila enheter, personer som inte har språket som modersmål, och användare i situationer med låg bandbredd där ljudkvaliteten redan kan vara försämrad. Det finns också indirekta SEO-fördelar: transkriptioner av tydligt begripligt ljud ger textinnehåll av högre kvalitet som sökmotorer kan indexera, vilket förbättrar upptäckbarheten av ditt innehåll.

Relaterade Axe-core-regler

WCAG 1.4.7 kräver manuell testning. Det finns ingen automatiserad axe-core-regel som kan upptäcka denna överträdelse, och detta är avsiktligt. Automatiska tillgänglighetsskannrar som axe-core, Lighthouse eller IBM Equal Access Checker fungerar genom att analysera en webbsidas DOM-struktur, HTML-attribut, ARIA-roller och beräknade stilar. De har ingen möjlighet att:

• Analysera ljudinnehållet i en fil: Skannrar kan inte öppna en ljud- eller videofil och mäta de relativa decibelnivåerna för tal i förgrunden jämfört med bakgrundsljud. Att göra detta skulle kräva ljudsignalbehandling långt utöver vad en DOM-baserad tillgänglighetskontroll klarar.
• Upptäcka om en separat bakgrundsljudkontroll finns och fungerar korrekt: Även om en UI-kontroll med etiketten ”Stäng av bakgrundsmusik” finns i DOM:en kan en skanner inte verifiera att den faktiskt dämpar bakgrundsljudspåret utan att påverka talspåret, och inte heller att kontrollen fungerar som förväntat i alla webbläsare.
• Skilja tal från icke-tal-ljud: Automatiska verktyg kan inte pålitligt klassificera en ljudfil som talprimär, musikprimär eller ambient-primär, vilket är den förutsättande bedömningen innan kriteriet ens är tillämpligt.

Eftersom all utvärdering måste göras av en mänsklig granskare som lyssnar på innehållet och vid behov använder ljudanalysprogram för att mäta decibelnivåer, markerar axe-core detta kriterium som kräver manuell granskning. När du kör axe DevTools mot en sida som innehåller <audio>- eller <video>-element kan verktyget visa en allmän medierelaterad rekommendation som påminner dig om att manuellt utvärdera ljudkvalitetskriterier, men det kommer inte automatiskt att ge ett godkänt eller underkänt resultat för 1.4.7.

Hur man testar

1. Inventera allt ljudinnehåll på sidan. Ladda sidan och identifiera varje <audio>-element, varje <video>-element med ett ljudspår, varje inbäddad podcast eller mediaspelare och eventuellt bakgrundsljud som spelas upp automatiskt. Avgör om varje ljud är förinspelat och innehåller tal i förgrunden. Om det är ett rent musikspår eller ambient ljud utan tal, är 1.4.7 inte tillämpligt.
2. Kör en automatisk skanning för grundläggande problem. Använd axe DevTools, Lighthouse eller Accsible-widgetens inbyggda granskning för att skanna sidan. Även om dessa verktyg inte bedömer ljudkvalitet kan de flagga saknade undertexter, avsaknad av controls-attribut på <audio>-element eller relaterade tillgänglighetsproblem för media. Åtgärda alla flaggade problem innan du går vidare till manuell ljudutvärdering.
3. Lyssna på varje kvalificerat ljudspår i sin helhet. Använd sidans inbyggda spelare eller ladda ner filen och öppna den i en mediaspelare. Lyssna specifikt efter bakgrundsmusik, omgivningsljud eller annat icke-tal-ljud som spelas samtidigt som talet i förgrunden.
4. Bedöm om bakgrundsljud kan stängas av oberoende. Om spelaren tillhandahåller en separat kontroll för att stänga av eller sänka bakgrundsmusiken utan att påverka röstspåret, verifiera att denna kontroll fungerar som förväntat i Chrome, Firefox och Safari. Testa med enbart tangentbordsnavigering för att bekräfta att kontrollen är tillgänglig.
5. Mät decibelnivåer om bakgrundsljud finns och inte kan stängas av. Importera ljudfilen i en gratis ljudredigerare som Audacity. Använd den inbyggda vågforms- eller spektrogramvyn och verktyget ”Analyze > Contrast” (eller motsvarande) för att mäta den genomsnittliga RMS-nivån för talsegmenten jämfört med den genomsnittliga RMS-nivån för bakgrundsljudsegmenten. Bekräfta att skillnaden är minst 20 dB. Om du inte har tillgång till ljudanalysprogram, använd ditt professionella omdöme som erfaren lyssnare: om en typisk person med mild hörselnedsättning skulle uppleva bakgrundsljudet som distraherande eller skymmande, behandla det som ett sannolikt fel.
6. Testa med hjälpmedelsteknik. Använd NVDA med Firefox, VoiceOver med Safari på macOS och JAWS med Chrome för att navigera till varje ljudspelare. Bekräfta att alla kontroller — inklusive eventuell separat bakgrundsljudväxel — kan nås med tangentbord (Tab/Shift+Tab), annonseras korrekt av skärmläsaren och kan användas med Enter eller mellanslag. Detta testar inte ljudkvaliteten direkt, men bekräftar att eventuella åtgärdskontroller du har lagt till är tillgängliga.
7. Dokumentera resultat. Notera vilka ljudfiler som är godkända (inget bakgrundsljud, användarkontroll tillgänglig eller 20 dB-skillnad bekräftad), vilka som är underkända och vilka som är undantagna (korta ljudeffekter under 2 sekunder eller ljud som främst är musik snarare än tal).

Hur man åtgärdar

Scenario 1: Bakgrundsmusik mixad för högt — Felaktigt

<!-- Audio file contains a narrator speaking over background music
     mixed at roughly equal volume levels. No separate control exists.
     This fails WCAG 1.4.7 because background audio is not 20 dB below speech
     and cannot be turned off independently. -->
<audio controls src='product-explainer.mp3'>
  Your browser does not support the audio element.
</audio>

Scenario 1: Bakgrundsmusik mixad för högt — Korrekt

<!-- The audio file has been re-exported with no background music.
     If background music is desired for branding, produce two separate
     audio tracks: one speech-only and one with music. Offer the
     speech-only version as the default accessible option. -->
<audio controls src='product-explainer-speech-only.mp3'>
  Your browser does not support the audio element.
</audio>
<p>
  <a href='product-explainer-with-music.mp3'>
    Listen to version with background music (may be harder to follow for some users)
  </a>
</p>

Scenario 2: Bakgrundsljud med en oberoende mute-kontroll — Felaktigt

<!-- A custom player claims to offer background audio control,
     but the button is not keyboard-accessible and has no accessible name.
     Sighted mouse users can click it, but screen reader users and
     keyboard-only users cannot reach or operate the control. -->
<div class='player'>
  <audio id='main-audio' src='lecture-with-ambience.mp3'></audio>
  <button onclick='document.getElementById("main-audio").play()'>Play</button>
  <div onclick='toggleBackground()' style='cursor:pointer'>
    <img src='music-icon.png'>
  </div>
</div>

Scenario 2: Bakgrundsljud med en oberoende mute-kontroll — Korrekt

<!-- The background audio toggle is now a proper <button> element with
     an accessible name, keyboard focus, and an aria-pressed state so
     screen readers announce whether background audio is on or off. -->
<div class='player'>
  <audio id='main-audio' src='lecture-with-ambience.mp3'></audio>
  <audio id='bg-audio' src='background-ambience.mp3' loop></audio>
  <button onclick='document.getElementById("main-audio").play()'>Play lecture</button>
  <button
    id='bg-toggle'
    aria-pressed='true'
    onclick='toggleBackground()'
  >
    Background audio: on
  </button>
</div>
<script>
  function toggleBackground() {
    var bg = document.getElementById('bg-audio');
    var btn = document.getElementById('bg-toggle');
    if (bg.paused) {
      bg.play();
      btn.setAttribute('aria-pressed', 'true');
      btn.textContent = 'Background audio: on';
    } else {
      bg.pause();
      btn.setAttribute('aria-pressed', 'false');
      btn.textContent = 'Background audio: off';
    }
  }
</script>

Scenario 3: Autoplay av bakgrundsljud vid sidladdning — Felaktigt

<!-- Background audio autoplays when the page loads and there is
     no way to turn it off. If a narrator audio also plays, the
     background audio will compete with it and cannot be suppressed. -->
<audio autoplay loop src='ambient-background.mp3'></audio>
<audio controls src='welcome-message.mp3'></audio>

Scenario 3: Autoplay av bakgrundsljud vid sidladdning — Korrekt

<!-- Background audio does not autoplay. A clearly labeled, keyboard-
     accessible button allows the user to opt in if desired. The speech
     audio is presented independently and cleanly without competition. -->
<audio id='bg' loop src='ambient-background.mp3'></audio>
<button onclick='document.getElementById("bg").play()'>
  Play background music (optional)
</button>
<audio controls src='welcome-message.mp3'>
  Your browser does not support the audio element.
</audio>

Vanliga misstag

• Att mixa bakgrundsmusik på -10 dB istället för de kräva -20 dB: Producenter sänker ofta bakgrundsmusikens volym måttligt och antar att det är tillräckligt. WCAG-standarden kräver en full 20 dB-skillnad (ungefär fyra gånger tystare), inte bara en märkbar sänkning. Verifiera alltid med ett ljudanalysverktyg istället för att enbart lita på subjektivt omdöme.
• Att förväxla spelarens övergripande volymkontroll med en oberoende bakgrundsljudkontroll: En huvudvolymslider som sänker både tal och bakgrundsljud samtidigt uppfyller inte villkoret ”användaren kan stänga av bakgrundsljud”. Kontrollen måste endast dämpa bakgrundsljudet utan att påverka talet i förgrunden.
• Att anta att kriteriet bara gäller fristående ljudfiler: Många utvecklare förbiser att ljudspåret i ett videoelement omfattas lika mycket av 1.4.7. En videoförklaring med hög bakgrundsmusik mixad i ljudspåret bryter mot kriteriet på samma sätt som en podcastfil skulle göra.
• Att behandla alla korta ljud som undantagna: WCAG-undantaget för korta ljudeffekter gäller endast ljud som varar två sekunder eller mindre. En återkommande kort jingle som upprepas var några sekund, eller en bakgrundsloop av korta ljud, omfattas inte av detta undantag och måste ändå följa kraven.
• Att inte testa bakgrundsljudväxeln med enbart tangentbordsnavigering: Team implementerar ofta en visuellt tilltalande muteknapp med ett icke-interaktivt element som ett <div> eller <span>, som inte kan nås med Tab-tangenten och inte kan användas med Enter eller mellanslag. Använd ett inbyggt <button>-element så att stöd för tangentbord och hjälpmedelsteknik finns inbyggt.
• Att glömma att lägga till aria-pressed eller motsvarande tillstånd på bakgrundsljudknappar: Utan en tillståndsindikator kan skärmläsaranvändare använda knappen men kan inte avgöra om bakgrundsljudet för närvarande är på eller av. Återge alltid det aktuella tillståndet i knappens tillgängliga namn eller via aria-pressed.
• Att bara producera en mixad ljudfil istället för att erbjuda separata spår: När bakgrundsljud är en integrerad del av den kreativa avsikten exporterar team ofta en enda mixad fil istället för att erbjuda ett tal-endast-alternativ. Att tillhandahålla en separat talversion kostar mycket lite extra produktionsinsats och eliminerar helt risken för bristande efterlevnad.
• Att tillämpa 1.4.7 på direktsända ljudströmmar: Kriteriet omfattar uttryckligen endast förinspelat ljud. Direktsända ljudsändningar omfattas inte av just denna regel, även om andra kriterier som 1.4.4 (Ändra textstorlek) och krav på undertexter fortfarande kan gälla för associerat innehåll.
• Att underlåta att kontrollera inbäddade tredjepartsspelare: När innehåll bäddas in från externa plattformar (podcasthostar, video-CDN:er, ljuddelningstjänster) antar team ofta att efterlevnaden är plattformens ansvar. Men sidägaren är ansvarig för tillgängligheten för allt innehåll på sina sidor, inklusive inbäddade medier. Verifiera att tredjepartsspelaren antingen uppfyller kraven på ljudkvalitet eller erbjuder nödvändiga kontroller.
• Att mäta toppnivåer istället för genomsnittliga RMS-nivåer när man kontrollerar 20 dB-kravet: 20 dB-tröskeln i WCAG 1.4.7 avser ljudets upplevda ljudstyrka, vilket bäst approximeras av genomsnittliga RMS-nivåer (Root Mean Square), inte momentana toppnivåer. Att använda toppnivåmätningar kan ge vilseledande gynnsamma värden som inte återspeglar den faktiska lyssningsupplevelsen.

Relation till Turkiets tillgänglighetsreglering

Turkiets presidentdekret 2025/10, publicerat i Officiella tidningen nr 32933 den 21 juni 2025, fastställer obligatoriska krav på digital tillgänglighet för ett brett spektrum av offentliga och privata aktörer som är verksamma i Turkiet. Cirkuläret antar WCAG 2.2 som sin normativa tekniska standard och definierar specifika krav på efterlevnad baserat på organisationstyp.

De aktörer som omfattas av obligatorisk efterlevnad enligt cirkuläret inkluderar offentliga institutioner och myndigheter på alla nivåer, e-handelsplattformar, banker och finansiella tjänsteleverantörer, sjukhus och vårdinrättningar, teleoperatörer med 200,000 eller fler abonnenter, licensierade resebyråer, privata transportföretag och privatskolor som godkänts av utbildningsministeriet (MoNE). Dessa organisationer måste uppfylla minst WCAG 2.2 nivå A och nivå AA.

WCAG 1.4.7 — Låg eller ingen bakgrundsljudnivå — är ett kriterium på nivå AAA. Detta innebär att det inte ingår bland de kriterier som berörda aktörer är juridiskt skyldiga att uppfylla enligt cirkulär 2025/10:s grundläggande krav. Flera viktiga överväganden gäller dock. För det första bör organisationer som frivilligt åtar sig AAA-efterlevnad — eller som betjänar grupper med hög andel användare med hörselnedsättning, såsom sjukhus, audiologikliniker eller socialtjänstmyndigheter — behandla 1.4.7 som i praktiken obligatoriskt i deras sammanhang. För det andra kommer alla aktörer vars digitala tjänster inkluderar talbaserat instruktionsinnehåll, inspelade kundtjänstsamtal, e-lärandemoduler eller informationssändningar riktade till allmänheten att märka att uppfyllandet av 1.4.7 avsevärt förbättrar den faktiska användbarheten av dessa tjänster för turkiska medborgare med hörselnedsättning.

Turkiet har en betydande befolkning med hörselnedsättning, och cirkuläret återspeglar ett statligt åtagande att säkerställa likvärdigt digitalt deltagande. Även om AAA-kriterierna i den tekniska standarden presenteras som ambitiösa mål uppmuntras särskilt turkiska offentliga institutioner att överträffa minimikraven där deras innehåll och resurser tillåter det. Att kunna visa efterlevnad av 1.4.7 signalerar organisatorisk mognad, minskar juridisk och reputationsmässig risk och positionerar turkiska digitala tjänster som ledande inom inkluderande design både nationellt och på internationella marknader där AAA-efterlevnad kan vara ett avtalskrav.