WCAG 1.3.6: Identifiera syfte

Vad den här regeln innebär

\n

WCAG 1.3.6 — Identify Purpose är ett kriterium på nivå AAA under Princip 1 (Perceivable) som utökar de befintliga kraven på struktur och semantik till en finare detaljnivå. Mer specifikt kräver det att syftet med varje användargränssnittskomponent, ikon, region och vissa inmatningsfält kan fastställas programmatiskt — vilket betyder att den semantiska informationen exponeras på ett sätt som webbläsare, webbläsartillägg och hjälpmedel kan läsa och agera på.

\n

Kriteriet bygger direkt på 1.3.1 (Info and Relationships) och 1.3.5 (Identify Input Purpose). Där 1.3.5 fokuserar på vanliga inmatningsfält för personuppgifter (namn, e-post, telefon osv.), breddar 1.3.6 kravet till alla användargränssnittsregioner och komponenter, inklusive navigationslandmärken, ikoner, knappar och interaktiva widgets. Kärnidén är att en användaragent eller ett personaliseringsverktyg ska kunna byta ut standardpresentationen — ersätta textetiketter med symboler, förenkla en rörig navigation eller lyfta fram de mest relevanta kontrollerna — baserat på maskinläsbar syftesdata inbäddad i markuppen.

\n

I praktiken uppfyller en sida 1.3.6 när den använder HTML5-landmärkeselement (såsom <header>, <nav>, <main>, <aside>, <footer> och <section>), tillämpar lämpliga ARIA-landmärkesroller där landmärkeselement inte används, exponerar syftet med ikoner och andra icke-textuella UI-komponenter via tillgängliga namn eller roller och — där det är tillämpligt — använder standardiserade syftestoken såsom de som definieras i W3C Personalization Semantics-specifikationen (tidigare känd som COGA Semantics-förslaget), till exempel via aui--attributvokabulären.

\n

En sida misslyckas när dess regioner implementeras som generiska <div>- eller <span>-behållare utan semantisk roll, när ikoner bär betydelse men saknar tillgängligt namn eller stödjande semantik, eller när interaktiva komponenter inte ger någon programmatisk signal om sin funktion utöver sitt synliga utseende. Ett officiellt undantag gäller: kravet gäller endast innehåll som implementeras med tekniker som har stöd för att identifiera den förväntade betydelsen. Om ingen stödjande teknik eller specifikation finns för en viss komponenttyp i en given teknikstack kan kriteriet inte rimligen tillämpas på den komponenten.

\n\n

Varför det är viktigt

\n

De primära mottagarna av WCAG 1.3.6 är personer med kognitiva och inlärningsrelaterade funktionsnedsättningar, inklusive dyslexi, uppmärksamhetsstörningar, tillstånd inom autismspektrumet, minnesnedsättningar och intellektuella funktionsnedsättningar. Enligt Världshälsoorganisationen lever ungefär 1 av 6 personer globalt — över en miljard individer — med någon form av betydande funktionsnedsättning, och kognitiva funktionsnedsättningar utgör en av de största och mest underbetjänade grupperna. Många av dessa användare har svårt med komplexa navigationsstrukturer, täta textmenyer och ikonbaserade kontroller som saknar semantisk förankring.

\n

Överväg ett konkret scenario: en användare med svår dyslexi förlitar sig på ett webbläsartillägg som ersätter standardnavigationsetiketter med personliga symboluppsättningar — bildbaserade ikoner från en kommunikationstavla som de använder i vardagen. För att denna ersättning ska fungera måste tillägget kunna avgöra att ett visst <div> faktiskt är ett navigationslandmärke, att en stjärnikon representerar ”lägg till i favoriter” och att en cirkulär pil representerar ”uppdatera”. Utan programmatiskt fastställbart syfte har tillägget inget att haka i, och ersättningen misslyckas tyst, vilket lämnar användaren med ett gränssnitt de inte kan tolka.

\n

Användare med motoriska funktionsnedsättningar som förlitar sig på switch access eller röststyrning har också stor nytta, eftersom syftesmedvetna verktyg kan generera genvägsöverlägg eller röstkommandokartor endast för kontroller vars funktion är maskinläsbar. Blinda användare som interagerar via skärmläsare gynnas av tydligt märkta landmärkesregioner, vilket gör att de kan hoppa direkt till <main>-innehåll eller hoppa över repetitiv navigation. Användare med nedsatt syn som använder webbläsarzoom eller egna stilmallar gynnas av landmärkesstrukturen eftersom den gör att webbläsaren kan omflöda innehållet förutsägbart.

\n

Utöver tillgänglighet ger implementering av den semantik som krävs av 1.3.6 mätbara SEO-fördelar. Sökmotorers crawlers använder landmärkes- och schemamarkup för att förstå sidstruktur, indexera innehållshierarkier och generera utökade sökresultat. En välstrukturerad sida med meningsfulla landmärkesregioner har större sannolikhet att få featured snippets och högre relevanspoäng. Det finns också en direkt användbarhetsvinst: sidor med tydlig semantisk struktur är enklare att underhålla, testa och vidareutveckla för utvecklingsteam, vilket minskar den långsiktiga tekniska skulden.

\n\n

Relaterade Axe-core-regler

\n

WCAG 1.3.6 kräver manuell testning utöver alla automatiserade kontroller. Automatiska verktyg kan verifiera förekomsten av semantisk markup men kan inte avgöra om den markuppen korrekt och fullständigt förmedlar syftet med varje komponent på samma sätt som en mänsklig testare skulle göra. Följande axe-core-regler är nära relaterade och fungerar som automatiserade ställföreträdare för aspekter av detta kriterium:

\n

\n
• region — Kontrollerar att allt innehåll på sidan finns inom en landmärkesregion. Den flaggar innehåll som ligger utanför något erkänt landmärkeselement eller ARIA-landmärkesroll. Även om denna regel inte testar noggrannheten i syftesidentifieringen säkerställer den att den strukturella grund som krävs av 1.3.6 finns. Ett fel innebär att betydande innehåll är osynligt för landmärkesbaserad navigation.
\n
• landmark-one-main — Verifierar att sidan innehåller exakt ett <main>-element eller element med role='main'. Detta är grundläggande för 1.3.6 eftersom huvud­innehållsområdet är en av de mest kritiska regionerna vars syfte måste vara identifierbart. Flera eller saknade <main>-landmärken gör det omöjligt för personaliseringsverktyg att isolera primärt innehåll.
\n
• landmark-complementary-is-top-level — Kontrollerar att <aside>-element eller role='complementary'-regioner inte är nästlade inuti huvud­innehållsområdet på ett sätt som felrepresenterar deras syfte. Felaktig nästling vilseleder hjälpmedel om relationen mellan regioner.
\n
• aria-allowed-role och aria-valid-attr-value — Flaggar ogiltiga eller olämpliga ARIA-rolltilldelningar. Eftersom 1.3.6 är beroende av korrekta rollsemantiker undergräver användning av en felaktig roll (t.ex. role='navigation' på en knappgrupp) aktivt syftesidentifieringen och dessa regler kommer att lyfta fram sådana missanpassningar.
\n
• button-name och link-name — Verifierar att interaktiva kontroller har tillgängliga namn. Knappar och länkar som enbart består av ikoner utan tillgängliga namn är ett primärt felmönster för 1.3.6, eftersom inget syfte kan fastställas för en kontroll utan namn. Dessa regler flaggar avsaknaden av aria-label, aria-labelledby eller synlig text.
\n

\n

Manuell testning krävs eftersom automatiserade verktyg inte kan bedöma om de valda syftestoken eller semantiska rollerna korrekt representerar komponentens verkliga funktion i applikationens kontext. En knapp kan ha ett tillgängligt namn och en giltig ARIA-roll men ändå inte uppfylla 1.3.6 om namnet är vilseledande eller rollen inte återspeglar vad kontrollen faktiskt gör.

\n\n

Hur man testar

\n

\n
1. Kör en automatiserad skanning med axe DevTools eller Lighthouse. Öppna sidan i Chrome, aktivera tillägget axe DevTools och kör en fullständig sid­skanning. Filtrera resultaten efter reglerna som listas ovan: region, landmark-one-main, button-name och link-name. Notera eventuella överträdelser och deras påverkan. I Lighthouse kör du en Accessibility-granskning och går igenom avsnitten om landmärken och ARIA. Dokumentera alla fel som en baslinje, men förstå att dessa endast representerar en delmängd av 1.3.6-efterlevnad.
\n
2. Inspektera landmärkesstrukturen manuellt med webbläsarens utvecklarverktyg. Öppna DevTools, gå till panelen Accessibility Tree (Chrome) eller Accessibility Inspector (Firefox) och verifiera att sidan exponerar en sammanhängande landmärkes­hierarki: ett <header> på toppnivå, ett <main>, minst ett <nav> (med en särskiljande etikett om flera finns) och ett <footer>. Bekräfta att ingen meningsfull innehållsregion endast är innesluten i ett generiskt <div> eller <span>.
\n
3. Testa med NVDA och Firefox. Starta NVDA, öppna sidan i Firefox och tryck på D för att växla mellan landmärken. Verifiera att varje landmärke annonseras med en meningsfull roll och, där flera landmärken av samma typ finns, en unik etikett. Navigera till varje ikonbaserad knapp med Tab-tangenten och bekräfta att NVDA annonserar ett beskrivande tillgängligt namn — inte en tom sträng, filnamn eller en generell etikett som ”button”.
\n
4. Testa med VoiceOver och Safari (macOS/iOS). Aktivera VoiceOver (Cmd+F5 på macOS). Använd Rotor (Vo+U) för att öppna listan Landmarks och verifiera att alla förväntade regioner visas. Tabba genom interaktiva kontroller och lyssna efter meningsfulla beskrivningar. På iOS använder du en svepning med tre fingrar för att navigera efter rubriker och landmärken och bekräftar att syftet med varje region annonseras korrekt.
\n
5. Testa med JAWS och Chrome. Öppna sidan i Chrome med JAWS igång. Tryck på R för att navigera mellan regioner och bekräfta att varje regions roll och etikett är korrekt. Använd JAWS Virtual Cursor för att läsa igenom ikonknappar och verifiera att deras syfte förmedlas. Använd JAWS List of Links (Insert+F7) för att granska alla länk­namn ur ett meningsfullhetsperspektiv.
\n
6. Testa personaliseringssemantik (om implementerad). Om din sida använder W3C Personalization Semantics-vokabulären (t.ex. data-purpose eller aui--attribut) använder du Personalization Semantics test tool eller ett kompatibelt webbläsartillägg för att verifiera att syftestoken är korrekt tillämpade och maskinläsbara av användaragenter som stöder specifikationen.
\n
7. Genomför en komponent-för-komponent-syftesgranskning. För varje interaktiv komponent och ikon på sidan, fråga: kan syftet med den här komponenten fastställas utan visuellt sammanhang? Om borttagning av all CSS och alla bilder ändå lämnar komponentens syfte tydligt utifrån DOM och ARIA-attribut ensamma, är den godkänd. Om syftet endast förmedlas visuellt, är den underkänd.
\n

\n\n

Hur man åtgärdar

\n\n

Generiska div-regioner utan landmärken — Felaktigt

\n

<div class='site-header'>\n  <div class='logo'>Accsible</div>\n  <div class='main-nav'>\n    <a href='/home'>Home</a>\n    <a href='/pricing'>Pricing</a>\n  </div>\n</div>\n<div class='main-content'>\n  <p>Welcome to our platform.</p>\n</div>\n<div class='sidebar'>\n  <p>Related articles</p>\n</div>\n<div class='site-footer'>\n  <p>© 2025 Accsible</p>\n</div>

\n\n

Generiska div-regioner utan landmärken — Korrekt

\n

<!-- Use native HTML5 landmark elements so browsers and AT\n     can programmatically identify the purpose of each region -->\n<header>\n  <a href='/' aria-label='Accsible home'>\n    <img src='logo.svg' alt='Accsible' />\n  </a>\n  <nav aria-label='Primary navigation'>\n    <a href='/home'>Home</a>\n    <a href='/pricing'>Pricing</a>\n  </nav>\n</header>\n<main>\n  <p>Welcome to our platform.</p>\n</main>\n<aside aria-label='Related articles'>\n  <p>Related articles</p>\n</aside>\n<footer>\n  <p>© 2025 Accsible</p>\n</footer>

\n\n

Endast ikonknapp utan tillgängligt namn — Felaktigt

\n

<!-- An icon button whose purpose cannot be determined\n     programmatically — it has no accessible name at all -->\n<button class='btn-icon'>\n  <svg viewBox='0 0 24 24' width='24' height='24'>\n    <path d='M12 2l3.09 6.26L22 9.27l-5 4.87 1.18 6.88L12 17.77l-6.18 3.25L7 14.14 2 9.27l6.91-1.01L12 2z'/>\n  </svg>\n</button>

\n\n

Endast ikonknapp utan tillgängligt namn — Korrekt

\n

<!-- aria-label gives the button a programmatically determinable\n     purpose; the SVG is hidden from AT since the label covers it -->\n<button class='btn-icon' aria-label='Add to favourites'>\n  <svg viewBox='0 0 24 24' width='24' height='24' aria-hidden='true' focusable='false'>\n    <path d='M12 2l3.09 6.26L22 9.27l-5 4.87 1.18 6.88L12 17.77l-6.18 3.25L7 14.14 2 9.27l6.91-1.01L12 2z'/>\n  </svg>\n</button>

\n\n

Flera navigationslandmärken utan särskiljande etiketter — Felaktigt

\n

<!-- Two nav elements with identical roles but no labels:\n     screen readers cannot distinguish their purpose -->\n<nav>\n  <a href='/home'>Home</a>\n  <a href='/about'>About</a>\n</nav>\n\n<nav>\n  <a href='/page1'>Chapter 1</a>\n\n
(Content truncated due to token limit — please retry this article.)