Se till att eventuella samtalsfunktioner är tillgängliga
När det finns funktioner för samtal med röst eller video ska dessa utformas på ett sätt som gör dem tillgängliga för så många som möjligt.
Sidan är ett utkast
Denna sida är en av flera nya webbriktlinjer som förtydligar och exemplifierar innebörden i de kriterier som går utöver WCAG i standarden EN301549, och som har relevans för DOS-lagen.
Kom gärna med synpunkter!
Exempelvis genom e-post till info@webbriktlinjer.se eller genom kommentarsfunktionen i slutet av sidan.
Rekommendationer om ni har funktioner för tvåvägs röstkommunikationLänk hit
- Säkerställ tillräcklig ljudkvalitet vid röstkommunikation.
- Komplettera röstkommunikation med realtidstext.
- Presentera den som ”ringer” på mer än ett sätt.
- Säkerställ tillräcklig kvalitet vid videokommunikation.
Säkerställ tillräcklig ljudkvalitet vid röstkommunikationLänk hit
När röster förekommer i systemet (vid tal eller talsyntes) ska frekvenser upp till 7 kHz kunna återges för tillräcklig ljudkvalitet.
Om inte de högre frekvenserna kan återges så blir det svårare att uppfatta och förstå tal, eftersom diskant-ljud som exempelvis bokstaven ”s” kan bli otydliga och exempelvis förväxlas med bokstaven ”f”.
I praktiken är det ovanligt med denna typ av problem, eftersom nästan alla tekniska system för röstkommunikation sedan länge tagit höjd för motsvarande krav, men det skulle kunna inträffa om exempelvis en alltför hög grad av komprimering används för ljud-data.
Observera att ljudkvalitet är en mycket viktig faktor för begriplighet i dialog. För de flesta användare är det exempelvis rationellt att avstå från bild/video vid ”dålig mottagning” om detta gör att överföringskapaciteten räcker för ljud utan störningar. Detta gäller dock inte alla användare, till exempel inte den som behöver stöd av läppavläsning.
Komplettera röstkommunikation med realtidstextLänk hit
Om det går att tala (tvåvägs röstkommunikation) genom systemet ska detta även erbjuda realtidstext (RTT) som komplement. Denna funktion ska kunna användas samtidigt som röstkommunikation, exempelvis för att kunna förtydliga enstaka termer som är svåra att uppfatta i tal.
Realtidstext innebär bland annat att text ska överföras till mottagare antingen vid varje tangentnedtryckning eller efter varje ord. (Av integritetsskäl är det lämpligt att användare görs medvetna om denna funktion, så att de inte oavsiktligt kommunicerar mer information än de tänkt.)
Det finns även vissa andra detaljkrav som berör realtidstext-funktionen. Exempelvis vad gäller interoperabilitet, se EN-standardens avsnitt 6.2.
Realtidstext är sedan länge etablerat inom texttelefoni, men inte lika vanligt i funktioner för text-chatt på internet. Därför kan just dessa krav för närvarande vara en utmaning i webbaserade system.
Presentera den som ”ringer” på mer än ett sättLänk hit
För tvåvägs röstkommunikation där det är möjligt att få information om vem som “ringer”, ska informationen om vem det är kunna presenteras i textform och åtminstone en ytterligare modalitet. Till exempel att namnet även läses upp av skärmläsare eller möjligen presenteras som punktskrift.
I webbsammanhang kan en skärmläsare presentera textinformation som plötsligt dyker upp om den kodas på rätt sätt, med exempelvis aria-live
. Se R164. Se till att hjälpmedel kan presentera meddelanden som inte är i fokus.
Säkerställ tillräcklig kvalitet vid videokommunikationLänk hit
Om funktionen för röstsamtal även erbjuder videokommunikation, exempelvis för användare som kommunicerar med teckenspråk eller läser läppar och ansiktsuttryck, så finns vissa minimikrav för bildkvalitet, det vill säga upplösning, uppdateringsfrekvens och synkronisering mellan bild och ljud. Uppdateringsfrekvens är i allmänhet den viktigaste av dessa faktorer. Ju högre videokvalitet desto bättre. Åtminstone upplösningen CIF, 20 bilder per sekund och en fördröjning mellan bild och ljud på max 0,1 sekunder rekommenderas. Då uppfylls minimikraven även i nästa (redan publicerade) version av EN-standarden, men följande minimikrav gäller än så länge:
- Den högsta möjliga upplösningen ska vara minst QCIF, vilket innebär 176 × 144 pixlar.
- Bildväxlingsfrekvensen ska vara minst 12 bilder per sekund vid ideala nätverksförhållanden.

Precis som med kraven på ljudkvalitet ovan är dessa tekniska krav relativt lågt ställda, särskilt med tanke på att kompromisser är godtagbara i händelse av tillfällig kapacitetsbrist. Överträffa dem gärna om det är möjligt utan att andra problem (såsom överbelastning i nät eller servrar) uppstår.
Vad säger standarder och lagar om denna riktlinje?Länk hit
Enligt DIGGs föreskrifter (§4) ska digital service som omfattas av lagen om tillgänglighet till digital offentlig service vara möjlig att uppfatta, vara hanterbar, begriplig och robust.
Eftersom dessa principer är svåra att utan vägledning tillämpa i enskilda detaljer erbjuds i §5 ett konkret sätt att uppfylla dem: Kriterierna i bilaga A i standarden EN301549 v2.1.2 (pdf). Denna webbriktlinje är ett försök att förklara och exemplifiera tre av dessa kriterier:
- 6.2 Realtidstext (RTT)-funktionalitet
- 6.3 Anropares ID
- 6.5 Videokommunikation
TerminologiLänk hit
CIF är en förkortning av Common Intermediate Format och kallas även FCIF (Full CIF). CIF motsvarar upplösningen 352 × 288 pixlar.
QCIF är en förkortning av Quarter Common Intermediate Format och motsvarar alltså en fjärdedels CIF, det vill säga 176 × 144 pixlar.
I kommande version av EN-standarden krävs respektive rekommenderas istället videoformaten QVGA och VGA. Det motsvarar en högre videokvalitet.
Uttrycket Anropares ID är kanske mer känt på engelska: Caller ID.
Kommentarer till denna riktlinje
Kommentarer (0)
Skriv kommentar
Funktionen för att skriva kommentarer använder kakor. Läs mer om kakorna. Enbart förstapartskakor används. Vill du inte godkänna kakor så kan du ställa in din webbläsare att blockera dem. Funktionen går ändå att använda men den kommer då att ställa vissa frågor om och om igen, och kan inte förhandsvisa dina kommentarer.
För att kunna erbjuda denna funktion behöver vi lagra de uppgifter som du själv skriver in (namn, e-post, eventuell webbadress och själva kommentaren) samt IP-nummer. Den rättsliga grunden är samtycke och informationen ligger kvar så länge DIGG bedömer att den tillför förståelse för riktlinjen, eller tills du begär att den raderas. Läs mer om DIGGs behandling av personuppgifter.