Identifiera syfte
Bortom formulärfält måste syftet med UI-komponenter, ikoner och regioner vara programmatiskt identifierbart — så att adaptiv teknik kan byta ut symboler, förenkla sidan eller dölja icke-väsentliga delar.
Vad det kräver
Där 1.3.5 enbart täcker formulärfält utvidgar 1.3.6 samma idé till alla UI-komponenter, ikoner och regioner. Avsikten är att ett adaptivt verktyg — ett kognitivt stödtillägg, en symbolöverlagringsapp — ska kunna identifiera en “sök”-region, en “navigering”-länk, en “radera”-knapp utifrån dess roll och syfte och sedan ersätta eller dölja den. Specifikationen är avsiktligt framåtblickande och underspecificerad.
Hur du uppfyller det
- Använd ARIA-landmärken (
role="navigation",role="search",role="main") och HTML5-sektionselement (<nav>,<main>,<search>) för att identifiera regioner. - För ikonknappar, se till att det tillgängliga namnet mappar till ett välkänt syfte (“Sök”, “Inställningar”, “Stäng”).
- Använd
rel-attribut på länkar (rel="next",rel="prev",rel="author") för att identifiera länkens syfte. - Använd schema.org eller mikrodata för att deklarera entitetstyper där adaptiva verktyg kan konsumera dem.
- Följ ARIA Authoring Practices Guide-mönster så att komponentroller är förutsägbara.
Vanliga fel
- Ikonknappar namngivna “Klicka här” eller utan tillgängligt namn, inget maskinläsbart syfte.
- Anpassade sökwidgetar utan
role="search"-landmärke och utan autocomplete-token. - En samling
<div>-element som visuellt formar navigering men saknar landmärksroll. - Anpassade “radera”-knappar som ser distinkta ut men annonseras identiskt som “redigera” eller “visa.”
Varför det spelar roll
AAA, och sällan obligatoriskt. Verktygsekosystemet som skulle konsumera dessa signaler är fortfarande under uppbyggnad, och många team betraktar 1.3.6 som ett framtidsmål. Om du redan uppfyller 1.3.5 och använder semantisk HTML med landmärken är du det mesta av vägen dit.