Hjälpmedelsguide för Xbox 106: Skärmberättelse

Mål

Målet med den här xbox-hjälpmedelsguiden (XAG) är att se till att all visuell information på skärmen också kan representeras ljudligt via programvara för skärmröst. Detta gynnar spelare som inte kan läsa på skärminnehåll på grund av saker som blindhet, nedsatt syn, inlärningssvårigheter eller tillfälliga/situationella omständigheter.

Översikt

Skärmberättelsetekniker används ofta av spelare som är blinda eller har nedsatt syn. Men det finns också spelare som kanske kan se skärmen tydligt men inte kan läsa på grund av ålder eller inlärningssvårigheter. Skärmläsaren visar information som syns på skärmen via en syntetiserad ljudröst. Element som menytext, instruktioner ("tryck på A för att välja") och visuell information i den aktiva spelmiljö som krävs för att spela berättas högt. Detta eliminerar behovet av att spelaren läser själva skärmen om de inte kan.

Skärmläsningstekniker kan användas via plattformsomfattande tekniker eller spelspecifika tekniker. Kontakta din plattformsleverantör för mer information för att avgöra om någon befintlig teknik på plattformsnivå kan användas av ditt specifika spel eller om du måste skapa ett skärmläsningssystem för ditt spel.

Oavsett om du utvecklar för en skärmläsare på plattformsnivå eller skapar en spelspecifik skärmläsningsteknik från grunden är det viktigt att ha följande riktlinjer i åtanke. De kan hjälpa till att säkerställa att alla nödvändiga delar av visuell information uttrycks korrekt och holistiskt för en spelare med hjälp av skärmläsningstekniker.

Omfångsfrågor

Granska först objekten i avsnittet "Vilka aspekter av spelet ska ha stöd för berättarröst?".

• Innehåller ditt spel något av dessa element?

• Presenterar dessa element viktig information för en spelare i ditt spel?

• Om en spelare inte kunde läsa något av dessa nyckeltextelement, skulle de blockeras från att konfigurera, starta eller spela spelet i sin helhet?

Bakgrund och grundläggande information: Skärmberättande

Introduktion till skärmberättelse

Det här avsnittet innehåller vägledning på hög nivå som är avsedd att hjälpa till att begränsa de grundläggande komponenterna i spel som ska ha stöd för skärmberättande.

Vilka aspekter av spelet bör stödja berättarröst?

Stöd för berättarröst innebär att även om ett objekt inte behöver berättas som standard, så läses dessa områden upp för spelaren om en spelare aktiverar sin konsol eller berättarfunktion i spelet.

• Allt på skärmtext:

  • Menyetiketter, underetiketter, roller, värden och beskrivningstext

  • Kontrolltyper/interaktionsmetod som "Tryck på A för att välja"

  • Gränssnittselement i spelet: heads up display (HUD) (t.ex. inventering eller hälsa), mål, tips/tips, kartor med mera.

    Exempel (kan expanderas)

    

    I Sea of Thieves visar de röda och gröna rektangulära indikatorerna de olika typer av text som visas på en enda menyskärm som ska stödjas av skärmberättelse. Detaljerad information om hur du berättar dessa objekt finns i avsnittet "Hur ska ett objekt berättas?" senare i det här avsnittet.

    Anmärkning

    Den här bilden har redigerats för att inkludera röda och gröna rektangulära indikatorer för att markera områden på skärmen som det här exemplet fokuserar på. Dessa röda och gröna rektanglar ingår inte i Sea of Thieves-användargränssnittet.

    

    Videolänk: berättar om skärminformation

    I det här exemplet med Gears Tactics berättas dialogrutan "taktisk kommunikation" helt så snart den visas på skärmen. Andra aspekter av spelupplevelsen berättas också, inklusive fiendens hälsa, träffberäkning, träffchans och crit-beräkning. Det här exemplet visar begreppet berättarröst bortom menyelement. Mer information om riktlinjer för bästa praxis när du berättar om HUD-element, tips, tips och andra element i spelet finns i "Hur ska ett objekt berättas?" och avsnitten "Resurser och verktyg" senare i det här avsnittet.

    Anmärkning

    Den här videon har redigerats för att inkludera gröna rektangulära indikatorer för att markera områden på skärmen som det här exemplet fokuserar på. Dessa gröna rektanglar ingår inte i användargränssnittet för kugghjulstaktik.

  • Kommunikation mellan spelare: inkommande partychattmeddelanden, alternativ för chatthjul eller förskrivna meddelandealternativ

    Exempel (kan expanderas)

    

    Videolänk: berättarröst för chatt

    I ett spel som Minecraft, där spelare kommunicerar enbart via sms, är det viktigt att berätta inkommande chattmeddelanden. Om en spelare inte kan läsa inkommande chattmeddelanden kan de inte svara på andra spelare eller vara helt involverade i multiplayer-atmosfären. När skärmberättande är aktiverat i spelet bör dessa inkommande meddelanden läsas upp för spelaren. I det här videoexemplet får en annan spelare meddelanden: "Hej! Välkommen till min värld! <3" – detta läses sedan upp av skärmläsaren.

    Förutom inkommande meddelanden som stöder skärmnarration bör alternativ för utgående meddelanden, såsom val av chatt-hjul och andra typer av förskrivna chattmeddelanden, läsas upp när skärmnarration är aktiverad. En spelare bör kunna veta vilket meddelande de skickar innan det skickas.

  • Bilder, diagram och tabeller

    Exempel (kan expanderas)

    Bilder som inte är dekorativa bör ha alternativa textbeskrivningar som läses upp via berättarröst. Diagram eller tabeller som ger informationsnyckel till spelet bör också ha beskrivningar på hög nivå som berättas. Innehållet i själva diagrammen och tabellerna bör också vara fullt tillgängligt.

    

    Bilder eller grafik som ger information som är nyckeln till spel måste också ha alternativa textbeskrivningar som kan berättas av en skärmläsare. I det här exemplet kan spelaren välja mellan enspelarläge eller flerspelarläge. Spelet har bara två bilder: en av en enda person som står ensam och en annan av flera personer som står tillsammans. Om en spelare inte kan se vad bilderna visar vet de inte vilket spelläge de väljer. I det här fallet meddelar skärmläsaren den beskrivande texten "single-player" när ikonen till vänster om den enskilde personen har fokus. Den meddelar också den beskrivande texten "multiplayer" när ikonen för flera personer i fokus är till höger, vilket säkerställer att spelare som inte kan se skärminnehåll inte blockeras från aspekter av ett spel som detta.

  • Uppdateringar och meddelanden i realtid (inkommande chattar, popup-meddelanden, felmeddelanden, vän som ansluter eller lämnar spelet)

    Exempel (kan expanderas)

    

    Videolänk: berättarröst om realtidsmeddelanden

    När skärmläsning är aktiverad i Minecraft, när en spelare ansluter till världen, läses textmeddelandet högt.

När ska berättande ske?

När någon av följande händelser inträffar bör dessa ändringar berättas korrekt.

• Ändra i kontext (öppna en dialogruta eller öppna en annan app)

  Exempel (kan expanderas)

  Detta avser alla större ändringar i innehållet på skärmen som en spelare är på. Dessa ändringar inkluderar händelser som att ändra från en menyskärm till en annan, en dialogruta som öppnas på skärmen eller andra viktiga händelser som, om de görs utan spelarens medvetenhet eller synlighet, skulle vara mycket förvirrande.

  

  Videolänk: berättarröst om kontextändringar

  I det här exemplet på sea of thieves-menygränssnittet sker en betydande förändring i kontexten varje gång en spelare går vidare till en ny skärm. Därför finns det en omedelbar beskrivning av skärmens aktuella titel ("Välj din upplevelse" > "Välj ditt skepp" > "Gallion" > "Välj din besättningstyp" > "laddar" > "öppnar besättningsregister").

  

  Videolänk: berättarröst om kontextändringar

  Vissa ändringar i kontexten är spelarinitierade, till exempel Sea of Thieves-exemplet, medan andra inte är det. I det här exemplet på Minecraft väljer spelaren sin sfär. När kontexten ändras till den lila inläsningsskärmen meddelas "Join Realm" medan belastningen pågår. När inläsningen är klar och spelaren nu befinner sig i spelmiljön, meddelas "Klar" för att indikera denna förändring i kontext från inläsningsskärmen till spelmiljön. Utan denna signal kanske en blind spelare inte vet när de är i den aktiva spelmiljön förrän en negativ händelse som att bli attackerad av en fiende ger en ljudsignal eller haptisk feedback. Att meddela att spelet har startat omedelbart eliminerar all osäkerhet eller potential för negativa händelser att hända spelaren.

  Anmärkning

  Det är bäst att inte ändra fokus utan spelarinitiering eller göra det mycket tydligt att kontexten kommer att förändras. I vissa fall, som laddningsskärmar, är detta oundvikligt.

• Fokusändring (gå till en annan knapp eller gå till ett annat spel i en spellista)

  Exempel (kan expanderas)

  

  Videolänk: berättarröst om fokusändring

  I det här exemplet på Gears 5, när fokus ändras till ett nytt menyelement, börjar berättelsen om det elementet. Berättarröst bör vanligtvis börja när det nya objektet får fokus.

  

  Videolänk: berättarröst för värdeändring

  I det här exemplet på Forza Horizon 4 meddelar berättarrösten ändringen i skjutreglagets nivåvärde varje gång spelaren flyttar skjutreglaget.

• Ändringar i realtidsmeddelanden, informationsändringar, felmeddelanden eller aviseringar

  Exempel (kan expanderas)

  

  Videolänk: felberättelse

  I det här exemplet med Gears 5 visas en dialogruta som innehåller ett felmeddelande. All information i den här felrutan meddelas spelaren så snart dialogrutan visas, så de är nu medvetna om kontexten för skärmen och hur du åtgärdar felet framöver.

Hur ska ett objekt berättas?

Alla element ska märkas, oavsett spelarens primära uppfattning. Om en seende spelare kan se och läsa en kontrolls etikett bör en icke-seende spelare höra samma etikett via berättarröst.

För både webb och programvara ges den här informationen vanligtvis till spelaren i ordning efter namn, roll, värde/tillstånd, indexering (om det behövs) och interaktionsinformation (om det behövs).

En berättelse ska innehålla följande viktiga information.

• Etiketter/namn

  Exempel (kan expanderas)

  

  I det här exemplet på menyn Jordade inställningar är följande exempel på hur de markerade "etiketterna" ska beskrivas programmatiskt och läsas för spelaren.

  "Kvalitet"

  "V-Sync"

  "Gamma"

• Kontrolltyper/roller

  Exempel (kan expanderas)

  I teorin är allt som en spelare kan navigera till i en spelmeny ett användbart objekt. Allt ska ha en kontrolltyp. Det föreslår hur man interagerar med det, så felaktighet här kan leda till en spelares oförmåga att upptäcka hur man interagerar med kontrollen.

  

  I det här exemplet representerar följande fraser hur de markerade etiketterna och kontrolltyperna på den här menyn ska beskrivas programmatiskt och läsas för spelaren.

  "Kvalitet, kombinationsruta"

  "V-Sync, växla"

  "Gamma, skjutreglage"

• Värden/tillstånd

  Exempel (kan expanderas)

  Många, om inte alla, menyalternativ har variabelvärden, även om variansen helt enkelt är "på" eller "av". För nedrullningsbara menyer/listor krävs även ytterligare tillkännagivande av kontrollens tillstånd ("komprimerad").  

  

  I det här exemplet representerar följande fraser hur de markerade etiketterna, kontrolltyperna och värdena på den här menyn ska beskrivas programmatiskt och läsas för spelaren.

  Kvalitet, rullgardinsmeny, kollapsad, Hög

  V-Sync, omkoppla, Av

  "Gamma, skjutreglage, 38%"

• Indexering/uppräkning

  Exempel (kan expanderas)

  Position och antal objekt i menyn. Hjälper icke-siktade spelare att förbli orienterade och säkra på att de har hittat alla kontroller.

  

  I det här exemplet representerar följande fraser hur de markerade etiketterna, kontrolltyperna, värdena och uppräkningen av positionering på den här menyn ska beskrivas programmatiskt och läsas för spelaren:

  "Kvalitet, rullgardinsmeny, komprimerad, Hög, 3 av 9"

  "V-Sync, växla, av, 5 av 9"

  Gamma, skjutreglage, 38%, 6 av 9

• Navigerings-/interaktionsmodeller

  Exempel (kan expanderas)

  De flesta spel på en plattform har standarder för kontroller. På Xbox är B-knappen nästan alltid likvärdig med Escape, men kanske inte alla spel använder höger stötfångare (RB) och vänster stötfångare (LB) för att flytta mellan undermenyer i menyn "Alternativ". Spelare med synförmåga har nästan alltid någon form av knappuppmaningar där det behövs, så samma information bör vara tillgänglig via berättelse.

  

  I det här exemplet representerar "A"-glyfen en visuell interaktionsprompt. En spelare som använder en skärmläsare bör också höra den här uppmaningen högt som "A att välja".

Andra viktiga begrepp

• Bekräftelse av åtgärd: Detta innebär att en spelare försökte göra något, och de vet att de gjorde det baserat på feedback. De behöver också veta vad de försöker agera på så att de har en förväntan på vad som kommer att hända för varje åtgärd. Spelaren konfigurerar till exempel sina önskade inställningar och vet hur de ska spara sin konfiguration från interaktionsprompten "tryck på A för att spara". Om de trycker på "A" och ingenting händer är de osäkra på om deras arbete har sparats. Om de trycker på "A" och spelet berättar "inställningar sparade" är spelaren medveten om att de har sparat den inställning som de vill ha och säkert kan gå vidare till nästa gränssnittsskärm.

• Användargränssnittshierarki och intuitiv navigeringsordning: Detta bör vara konsekvent och intuitivt för spelare. Detaljerad vägledning om det här området finns i XAG 112: UI-navigering.

  Försiktighet

  Överdriv inte berättarrösten. Även om det är viktigt att se till att all nödvändig information förmedlas till en spelare med skärmläsning aktiverat, kan för mycket berättande lätt bli repetitivt och distraherande för en spelare.

  • I stället för att till exempel berätta ett textchattmeddelande som "iheartgames4ever 'you go left, I'll go right', trycker du på d-pad upp för att aktivera chattfönstret. Gå till inställningar för att ändra genväg. Gå till inställningar för att ändra mängden information som du hör när du får en chatt."

  • Du kan förenkla berättarrösten genom att läsa in nyckelinformationen i förväg och eliminera repetitiv berättarröst i realtid. Det är dock viktigt att se till att dessa kommandon eller alternativ kan hittas i inställningarna eller som en enda påminnelse i själva chattfönstret.

    • Förenklat exempel: "iheartgames4ever 'du går vänster, jag går höger'."

Implementeringsriktlinjer

• All grundläggande spelgränssnittstext (huvudmeny, alternativ, HUD, tillståndsändringar, spelare i spelet och tidsbaserade händelser) bör stödja skärmläsare som är tillgängliga på plattformen eller röst från användargränssnittet via en talsyntes. Användningen av inspelade ljudfiler kan också vara en lösning men är inte idealisk. (Alla referenser till "text" refererar till text som kan uttryckas med hjälp av dessa tekniker.)

  Exempel (kan expanderas)

  Interaktionsbara gränssnittselement bör ha textalternativ som beskriver deras funktion så att spelarna vet vad innehållet är, varför det finns där och vilka indata som krävs för att interagera med det (om innehållet är en kontroll).

  

  Videolänk: textalternativ för interaktiva gränssnittselement

  I Forza Horizon 4, på den första skärmen, tas spelaren dit efter att spelet har laddats. Det finns två interaktionsbara alternativ som spelaren måste välja mellan för att gå vidare. Spelets skärmberättelse läser korrekt de interagerbara knappuppmaningarna på skärmen som "Tryck på A-knappen för att starta" och "Tryck på X-knappen för tillgänglighet".

• Interaktionsbara gränssnittselement som fungerar som listor, flikar, alternativknappar, bocklistor eller kombinationsrutor måste räkna upp hur många underordnade objekt som tillhör elementet, vilken typ av indata elementet kräver, samt det aktuella tillståndet eller värdet för det indataelementet. Till exempel "Världar, flik, 1 av 3, vald" eller "Musikvolym, skjutreglage, 52%"

  • Uppräkning bör ske i slutet av en berättad sträng. Till exempel "Gama, skjutreglage, 38%, 6 av 9.".

  • Ett alternativ för att inaktivera uppräkningsberättelse kan tillhandahållas för spelare som föredrar förenklad berättarröst.

  Exempel (kan expanderas)

  

  Videolänk: berättarröst för interaktionsbara gränssnittselement

  I det här exemplet på hjälpmedelsmenyn Forza Horizon 4 är följande aspekter av användargränssnittselementet i fokus korrekt berättade.

  "Alternativet är markerat: Onlinehändelsemeddelanden": Informerar spelaren om etiketten för det element som för närvarande har fokus.

  "Alternativ 7 av 8": Hjälper till att orientera spelaren och informerar dem om hur många "inställningar" alternativelement som är tillgängliga i den här menyn. I det här fallet vet de att det finns åtta menyelement totalt, och de är för närvarande på den sjunde.

  "Kontrolltyp: Värdeväljare": Informerar spelaren om vad indata är för den här inställningen (i motsats till en listruta/lista, skjutreglage eller kryssruta).

  "Current Value: Off": Informerar spelaren om vilket aktuellt värde som anges. (Om de till exempel inte skulle vidta några åtgärder för att ändra det här värdet är detta vad deras aktuella spelinställning kommer att förbli på.)

  "Värde 1 av 2": Informerar spelaren om att det finns två totala värdealternativ för "Onlinehändelsemeddelanden" att välja mellan. Det finns ytterligare ett utöver deras aktuella värde av "Avstängd".

  Läser Beskrivning av element: "Inaktivera meddelanden för nya Horizon Life Events": Informerar spelaren om syftet med den här inställningen. Ser till att spelare som använder hjälpmedelstekniker som skärmberättande får information i paritet med alla andra spelare, inklusive seende spelare som kan läsa den här informationen om de vill.

  "A-knapp Acceptera", "B-knapp Tillbaka", "Y-knapp Återställ till standard": Informerar spelaren om den inmatningsmekanism eller interaktionsmodell som krävs för att genomföra de ändringar de vill göra.

  Anmärkning

  När element som beskrivningen och interaktionsmodellen/indatamekanismen har lästs upp upprepas inte dessa objekt igen efter varje ändring av fokus eller värde på den här menyn. Det beror på att informationen av den här typen inte har ändrats medan spelaren är inom ramen för den här användargränssnittsskärmen. Sådana berättelser kan bli distraherande och repetitiva för spelare.

• Textalternativen för diagram, bilder och animeringar bör göra samma information tillgänglig i en form som kan återges via auditiva utdata. Textalternativ kan användas vid behov för att förmedla informationen i innehållet som inte är text.

  Exempel (kan expanderas)

  

  Spel som presenterar information i form av diagram, bilder, animeringar eller annan grafik bör ha lämplig alternativ text som beskriver innehållet. I det här exemplet på ett diagram som visar spelets kontrollschema bör följande textalternativ skrivas och läsas upp av skärmläsaren när spelkontrollens grafik eller skärm får fokus.

  "Spelkontroller"

  "Sikta åt vänster – <Pausa> vänsterpil"

  <Dubbel paus>

  "Sikta åt höger – <pausa> högerpiltangenten"

  <Dubbel paus>

  "Långdistansskott – <Pausa> med Upp-piltangent"

  <Dubbel paus>

  "Närbildsskott – <Pausa> Nedåtpil"

  <Dubbel paus>

  "Fire – <Pausa> högerklicka med musen"

  <Dubbel paus>

  Boost Blast – <Pausa> vänsterklicka med musen

  Även om ordningen på informationen ska presenteras i en ordning som är mest intuitiv för en spelare, är huvudsyftet att se till att all information som kan samlas in visuellt från det här diagrammet också återges via ljudutdata från skärmläsaren.

• Se till att textalternativ för grafik förmedlar syftet med och driften av gränssnittskomponenterna.

  Exempel (kan expanderas)

  

  Videolänk: Textalternativ

  I Grounded läses textalternativet för "Arachnophobia Safe Mode" spindelförhandsvisningsfönstret av skärmberättelseprogramvaran som "Vänster musknapp för att visa spindelförhandsvisning". Det här är rätt sätt att skriva textalternativ eftersom den läser musikonen i textsträngen som "Vänster musknapp" i stället för "symbol" eller en annan programmatiskt felaktig alternativ textetikett.

• Icke-textinnehåll som är rent dekorativt, som endast används för visuell formatering eller som inte visas visuellt, ska inte läsas upp.

  Exempel (kan expanderas)

  

  Videolänk: dekorativa bilder

  I det här exemplet från Forza Horizon 4, när menyelementet för inställningar får fokus, läser berättarrösten: "Markerat alternativ: Inställningar, Kontrolltyp: Knapp..." Trots att kugghjulsgrafiken finns på inställningsmenyelementet bekräftas inte dess närvaro eller läses upp av skärmläsaren eftersom kugghjulet bara är ett dekorativt element. På samma sätt, molngrafiken, bilderna av bilar på menyn "Ändra bil", "lås"-symbolerna som finns på inaktiverade element, och många andra meddelas inte heller av skärmläsaren eftersom de är dekorativa. Dessa bilder ger ingen funktionell information som inte redan finns i form av textetiketterna på elementen.

• Stöd för en fokusordning som är anpassad efter innebörden eller driften av användargränssnittet. Om navigeringssekvensen är oberoende av innebörden eller åtgärden justerar du fokusordningen med flödet i den visuella designen.

  Exempel (kan expanderas)

  

  Videolänk: fokusordningen är justerad efter innebörden/driften av användargränssnittet

  Undermenyn "Huvudmeny" och "Inställningar" i Forza Horizon 4 är exempel på UIs som inte följer ett linjärt informationsflöde. Paneler placeras bredvid, eller på vardera sidan av, varandra, i stället för linjära UIs som inställningsmenyn i Sea of Thieves. I båda exemplen uppfyller implementeringen av fokusordningen den här XAG-vägledningen. Sea of Thieves fokusordning rör sig linjärt upp och ner, som en seende spelare kan förvänta sig. Menysekvensen i Forza Horizon 4 följer inte någon tydlig, linjär UI-sökväg. Fokusordningen överensstämmer dock med flödet för användargränssnittets visuella design (till exempel när en spelare har fokus på elementknappen Inställningar, initierar en kontroll för att flytta fokus nedåt resulterar i fokuslandning på knappen "Drönarläge".) Om en enda nedtryckning hade flyttat fokus från "Inställningar" till "Ändra bil" eller något annat menyelement som inte är visuellt intuitivt, skulle den här designen inte följa innebörden eller driften av användargränssnittet.

• När du har navigerat till det sista objektet i användargränssnittet/menystrukturen ska spelaren tas tillbaka till det första objektet i gränssnittet/menystrukturen och vice versa.

  Anmärkning

  Den här riktlinjen gäller endast för linjära menystrukturer där fokus kan flyttas upp eller ned eller till vänster eller höger. Menystrukturer som gör att fokus kan flyttas till element i valfri riktning (till exempel en meny med fokuserbara objekt ordnade i en 4 × 4 ruta) behöver inte loopa.

  Vi rekommenderar att utvecklare ska kunna slå på och slå av menyslingor för alla menyer.

  Exempel (kan expanderas)

  

  I den här skärmbilden av användargränssnittet för Probleminställningar för Forza Horizon 4 kan fokus bara flyttas uppåt och nedåt. Därför bör menyer med den här typen av struktur loopas tillbaka till det första elementet i listan. Detta inträffar när en spelare flyttar fokus "nedåt" till det efterföljande objektet när de för närvarande är på det sista fokusbara objektet i listan.

  

  I den här skärmbilden från fliken Forza Horizon 4 Horizon Life ordnas objekt så att spelarna kan flytta fokus uppåt, nedåt, vänster och höger. I flerriktade menystrukturer som den här bör fokus inte loop till det "första" objektet i listan när fokus flyttas från det "sista" objektet i listan.

• Spelare bör snabbt kunna avbryta/upprepa berättarröst, oavsett indatatyp (styrenhet, tangentbord, mus eller touch).

• Om berättarrösten för det aktuella objektet i fokus aktivt läss och fokus flyttas till ett annat gränssnittselement innan berättarsträngen har lästs i sin helhet, bör berättarrösten för det ursprungliga användargränssnittselementet omedelbart stoppas och berättarrösten för det nya användargränssnittselementet som fokus senast flyttades till ska börja.

  Exempel (kan expanderas)

  

  Videolänk: spelarinitierade kontextändringar

  I Assassin's Creed Valhalla när menyberättelsen är aktiverad slutar den aktuella berättarsträngen som läses upp omedelbart att spela när spelaren flyttar fokus till ett annat menyelement. När fokus har ändrats läses det aktuella menyalternativet som just har fått fokus upp. Spelare tvingas inte vänta tills hela textsträngen från ett tidigare objekt läses upp helt innan texten i det nyligen fokuserade objektet läses.

• Tillåt spelare att justera talarfrekvensen och tonhöjden för den röst som används för att berätta användargränssnittet.

  Exempel (kan expanderas)

  

  Videolänk: spelarinitierade kontextändringar

  I Assassin's Creed Valhalla kan spelarna justera takten i vilken text berättas samt menyrösten. Kvinnliga och manliga berättarröster tillhandahålls. Spelare kan välja mellan dessa två röstalternativ beroende på deras förmåga att lättare höra ljud med högre tonhöjd eller lägre tonhöjd, eller baserat på personlig preferens.

• Kontextändring ska vara spelarinitierad. När en kontextändring har inträffat bör spelaren meddelas via berättarröst om den nya kontexten.

  Exempel (kan expanderas)

  

  Videolänk: spelarinitierade kontextändringar

  I det här exemplet på Sea of Thieves-menygränssnittet är byte av kontext från en skärm till en annan initierat av spelaren. Spelaren måste trycka på knappen "A" för att välja ett alternativ innan en kontextändring sker. Spelaren tryckte till exempel på "A" när alternativet "Adventure" hade fokus. Det här valet initierade sedan en ändring från skärmen "Välj din upplevelse" till skärmen "Välj ditt skepp". Den här ändringen i kontext åtföljs av en omedelbar berättelse om den nya skärmens rubrik. ("Välj din upplevelse" > "Välj ditt skepp" > "Galleon" > "Välj din besättningstyp" > "loading, opening crew ledger").

• Spelare bör meddelas via berättarröst om händelser som är relevanta för användarinteraktioner (ändringar i komponenttillstånd, värde eller beskrivning). Detta inkluderar återkommande/tidsbaserade meddelanden, till exempel indikationer på speltillstånd. (Till exempel laddningsskärmar, söka efter spelarmeddelanden eller nedräkningstimers.) I dessa fall är det acceptabelt att läsa upp tillståndet var 7–10:e sekund för att inte störa andra berättelser/meddelanden.

  Exempel (kan expanderas)

  

  Videolänk: berättande av händelser som är relevanta för spelarinteraktioner

  I Gears 5 berättas antalet sekunder kvar i nedräkningstimern varje sekund. Även om det inte är nödvändigt att tillkännage varje sekund, eftersom var 5–10:e sekund är en acceptabel takt, kanske vissa spelare föredrar den här typen av nedräkning, särskilt när nedräkningen närmar sig noll. Dessutom är sekund-för-sekund-implementeringen av nedräkningstimerns berättarröst i det här exemplet acceptabel eftersom den inte stör andra berättelser eller meddelanden. När spelaren flyttar fokus till ett skärmelement som "Horde Frenzy" pausas timerns nedräkning automatiskt, meddelar objektet som nyligen fick fokus, och återupptas inte förrän rörelsen som spelaren initierade har stoppats. Dessutom, i det här exemplet sker berättelse när skärmkontexten ändras från en inläsningsskärm till själva spelmiljön. Detta informerar spelarna om att spelet har startat och att de inte längre är på inläsningsskärmen.

• När du stöder externa skärmläsare (jämfört med att implementera talsyntes i spelet) ska du göra följande:

  • Programmatiskt tillgängliggöra spelets språk. Det innebär att om spelet är på engelska (till exempel menyerna är skrivna på engelska, all text och instruktioner är på engelska eller tecken talar till varandra på engelska), bör spelet tilldela språkattributet för engelska (till exempel en-us), och se till att den här informationen exponeras för extern programvara som skärmläsare. Detta säkerställer att skärmläsaren meddelar information med rätt uttal och dialekter.

  • Om en dialog mellan icke-spelare innebär att tala på ett språk som skiljer sig från huvudspråkattributet som tilldelats spelet, bör detta också exponeras för skärmläsaren. Till exempel exponerar ett spel som har text, menyelement och majoriteten av teckendialog på engelska på lämpligt sätt spelets språk som "Engelska – USA" för externa skärmläsare. Det finns dock några omständigheter i spelet där en icke-spelare karaktär (NPC) talar till sin mamma, som bara talar spanska. Dialogen mellan karaktären och deras mor är på spanska. I det här fallet bör spelet också programmatiskt exponera områden i spelet där dialog eller annat språk skiljer sig åt. Detta säkerställer att när en skärmläsare läser dialogtexten högt för spelaren, använder den också rätt uttal för det spanska språket.

    Anmärkning

    Egennamn, tekniska termer, ord av obestämt språk och ord eller fraser som har blivit vedertagna eller allmänt använda i den omedelbara omgivande texten är undantag från dessa riktlinjer.

    • Exempel: Spelet är främst på engelska, men fraser som "hors d'oeuvers" eller andra vanliga fraser som är tekniskt på ett annat språk, är en del av ett fiktivt språk eller är rätt namn/tekniska term för något (till exempel Arc de Triomphe du Carrousel) behöver inte ytterligare programmeringsspråkattribut.

  • När du skriver alternativa textbeskrivningar för bilder, grafik, ikoner eller diagram ska du inte ta med typen av objekt i beskrivningen. (Om du till exempel skriver alternativ text för en bild av en sköld ska den alternativa texten vara "Brun sköld" i stället för "Bild: Brun sköld").

  • I innehåll som implementeras med hjälp av påläggsspråk har element fullständiga start- och sluttaggar, element kapslas enligt deras specifikationer, element innehåller inte dubblettattribut och eventuella ID:n är unika. (Detaljerade artiklar om hur du använder markeringsspråk finns i avsnittet "Resurser och verktyg" senare i det här avsnittet.)

  • För alla komponenter i användargränssnittet (inklusive men inte begränsat till formelement, länkar och komponenter som genereras av skript) kan namn och roll fastställas programmatiskt. Tillstånd, egenskaper och värden som kan anges av användaren kan anges programmatiskt. Meddelanden om ändringar av dessa objekt är tillgängliga för användaragenter, inklusive hjälpmedelstekniker.

• Ange ett textalternativ som beskriver alla tidsbaserade medier (som att tillhandahålla en ljudbeskrivning för en video).

• För liveinnehåll räcker det om textalternativet ger en beskrivande rubrik för det tidsbaserade medieelementet. (För en live-klockvisning läser skärmläsaren till exempel rubriken som "Klockan visar aktuell tid i Pacific Standard Time Zone", men behöver inte upprepade gånger meddela aktuell tid i realtid när den ändras.)

• Tabeller bör göras fullt tillgängliga för skärmberättelsetekniker.

  • Detta uppnås genom att se till att kolumn- och radrubriker är programmatiskt associerade med relevanta celler. Detta stöder en spelares förmåga att härleda nödvändiga kontexter om informationen som tillhandahålls i varje enskild cell. Alternativa textbeskrivningar på hög nivå för tabeller bör undvikas.

    Exempel (kan expanderas)

    Följande fabricerade tabeller och tillhörande beskrivningar visar skärmberättelsetexten som ska läsas upp när en spelare navigerar i enskilda celler i en tabell.

    

    Dessa tabell-modeller tillhandahålls som bilder i det här exemplet. De är dock avsedda att hjälpa dig att förstå hur skärmberättelse ska läsas upp eftersom en spelare navigerar mellan kolumnerna och raderna i en faktisk tabell som finns i ett spels användargränssnitt, webbplats eller annat dokumentationsområde.

    Encellsläsning

    

    När en användare flyttar fokus till den aktuella cellen som anges i den här tabellen bör skärmläsaren läsa följande information: Kolumnnummer, radnummer. Kolumnrubrik, radrubrik. Cellinnehåll. Den exakta textsträngen som berättas ska vara: "Kolumn 2, rad 2. Nivå 1 fiender, Guldmynt, 16."

    Rörelse mellan cellkolumner

    

    När du flyttar vänster eller höger inom samma rad till en ny cell ska skärmläsaren läsa: Kolumnrubrik, kolumnnummer, cellinnehåll. Den exakta textsträngen som berättas bör vara: "Nivå 2 Fiender, kolumn 3, 54."

    Flytta mellan cellrader

    

    När du flyttar upp eller ned i samma kolumn till en ny rad ska skärmläsaren läsa: Radrubriken, radnumret, cellinnehållet. Den exakta textsträngen som berättas bör vara: "Silvermynt, rad 3, 24."

• Ge spelaren en mekanism för att förstå hur man uttalar ett korrekt namn, en teknisk term eller ett ord av obestämt språk.

Potentiell spelarpåverkan

Riktlinjerna i denna XAG kan bidra till att minska hindren för följande spelare.

Resurser och verktyg