Die meisten Rollen, die Sie sehen, wurden im Rahmen von ARIA 1.0 definiert und später in HTML über unterstützende Spezifikationen wie HTML-AAM eingebunden. Einige der neuen HTML5-Elemente (Dialog, Haupt usw.) basieren sogar auf den ursprünglichen ARIA-Rollen.
http://www.w3.org/TR/wai-aria/
Während die Erste Regel von Aria besagt:
Wenn Sie bereits ein natives HTML-Element oder Attribut mit der gewünschten Semantik und Funktionalität verwenden können, anstatt ein Element umzufunktionieren und eine ARIA-Rolle, ein State oder eine Eigenschaft hinzuzufügen, um es zugänglich zu machen, dann tun Sie das.
gibt es einige Hauptgründe, zusätzlich zu Ihrem nativen semantischen Element Rollen zu verwenden.
Grund #1. Überschreibung der Rolle, wenn kein geeignetes Host-Sprachelement vorhanden ist oder aus verschiedenen Gründen ein weniger semantisch geeignetes Element verwendet wurde.
In diesem Beispiel wurde ein Link verwendet, obwohl die resultierende Funktionalität eher buttonartig als ein Navigationslink ist.
Löschen
Bildschirmleser-Benutzer werden dies als Schaltfläche (anstatt als Link) hören, und Sie können einen CSS-Attributselektor verwenden, um class-itis und div-itis zu vermeiden.
[role="button"] {
/* Diese wie Schaltflächen formatieren, ohne auf eine .button-Klasse angewiesen zu sein */
}
[Update 7 Jahre später: Der *-Selektor wurde entfernt, um einigen Kommentatoren Freude zu bereiten, da die alte Browser-Macke, die einen universellen Selektor bei Attributselektoren erforderte, im Jahr 2020 nicht mehr notwendig ist.]
Grund #2. Unterstützung eines nativen Elementrolle zur Sicherung von Browsern, die die ARIA-Rolle implementiert haben, aber die Rolle des nativen Elements noch nicht implementiert haben.
Zum Beispiel wird die "main"-Rolle seit vielen Jahren von Browsern unterstützt, aber sie wurde erst kürzlich zu HTML5 hinzugefügt, daher unterstützen viele Browser die Semantik für
noch nicht.
…
Das ist technisch redundant, hilft jedoch einigen Benutzern und schadet niemandem. In einigen Jahren wird diese Technik wahrscheinlich für main unnötig werden.
Grund #3. Update 7 Jahre später (2020): Wie von mindestens einem Kommentator angemerkt, ist dies nun sehr nützlich für benutzerdefinierte Elemente, und es wird an spezifischen Arbeiten gearbeitet, um die standardmäßige Zugänglichkeitsrolle eines Webkomponente zu definieren. Selbst wenn/ Sobald diese API standardisiert ist, kann es notwendig sein, die Standardrolle einer Komponente zu überschreiben.
Hinweis/Antwort
Sie haben außerdem geschrieben:
Ich sehe, dass einige Leute ihre eigenen Rollen erfinden. Ist das erlaubt oder eine korrekte Verwendung des roll-Attributs?
Dies ist eine zulässige Verwendung des Attributs, es sei denn, es ist keine tatsächliche Rolle enthalten. Browser wenden die erste erkannte Rolle in der Token-Liste an.
...
Aus der Liste sind nur link und note gültige Rollen, sodass die Link-Rolle in der platform Accessibility API angewendet wird, weil sie zuerst kommt. Wenn Sie benutzerdefinierte Rollen verwenden, stellen Sie sicher, dass sie nicht mit einer definierten Rolle in ARIA oder der Hostsprache, die Sie verwenden (HTML, SVG, MathML usw.), in Konflikt stehen.
