iFrames sollte ein Titelelement im übergeordneten Tag enthalten.</p></li> <li><p>Als Best Practice empfiehlt es sich, das Scrollen im <iframe> auf „Auto“ oder „Ja“ zu setzen. Tag-Einstellungen. Dadurch können Menschen mit Sehbehinderung in Inhalte innerhalb des <iframe> scrollen. dass sie sonst vielleicht nicht sehen könnten.</p></li> </ul> <h2> Fokusreihenfolge </h2> <ul> <li>Die Standard-Fokusreihenfolge muss logisch und intuitiv sein und mit der visuellen Reihenfolge einer Seite übereinstimmen.</li> </ul> <h2> Tabindex </h2> <ul> <li><p>Ein Element, das normalerweise fokussierbar ist, sich aber in einem inaktiven Zustand befindet (z. B. ein deaktiviertes Eingabefeld oder eine deaktivierte Schaltfläche), sollte einen negativen Tabindex (tabindex="-1") erhalten.</p></li> <li><p>Sollte den Fokus wieder auf das Element legen, wenn es aktiv ist oder benötigt wird (kann JS oder TS verwenden).</p></li> <li><p>Positiver Tabindex sollte vermieden werden. Den Fokus auf nicht interaktive Elemente zu legen und die normale Fokusreihenfolge zu stören, kann die Benutzer verwirren und frustrieren. In seltenen Fällen rechtfertigen Umstände das Hinzufügen eines positiven Tabindex, z. B. Tabindex=1, zu einem nicht fokussierbaren Element.</p></li> </ul> <h2> Links überspringen </h2> <ul> <li><p>Es muss ein Link zum Überspringen enthalten sein, damit Benutzer das Navigationsmenü umgehen können.</p></li> <li><p>Der Link zum Überspringen sollte Kontext zum Zweck des Links enthalten (z. B. „Zum Hauptinhalt springen“) und kann zusätzliche ARIA-Eigenschaften wie aria-labelledby, aria-label verwenden.</p></li> <li><p>Der Link zum Überspringen kann sichtbar oder visuell ausgeblendet sein (je nach Design), bis ein Benutzer darauf tippt.</p></li> </ul> <h2> Fokusanzeige </h2> <ul> <li>Stellen Sie sicher, dass die Fokusanzeige nicht unter anderen Komponenten verborgen ist.</li> </ul> <h2> Standardstil des Browsers </h2> <ul> <li><p>Sollte den standardmäßigen Browser-Fokusstil nicht überschreiben (z. B. „Umriss: 0“ oder „Umriss: keine“).</p></li> <li><p>Benutzerdefinierte Fokusstile sind zulässig.</p></li> </ul> <h2> JavaScript </h2> <h3> Trigger-Ereignisse </h3> <ul> <li>Wenn ein Klickereignis (z. B. onClick()) auf nicht-semantische Elemente (z. B. <div>) angewendet wird, muss ein Keydown-/Keyup-Ereignis hinzugefügt werden, um das Drücken der Eingabe- oder Leertaste zu erkennen.</li> </ul> <h3> Seitentitel </h3> <ul> <li>Jede Seite sollte einen Titel haben. Es ist akzeptabel, für diesen Zweck die Eigenschaft document.title oder ein Paket eines Drittanbieters zu verwenden</li> </ul> <h3> Dynamischer Inhalt </h3> <div><table> <tr> <th>Possible misuse</th> <th>Correct use</th> </tr> <tr> <td>Render large chunks of non-semantic HTML</td> <td>Render smaller pieces of semantic HTML</td> </tr> <tr> <td>Not allowing time for dynamic content to be recognized by assistive technology</td> <td>Using a setTimeout() time delay to allow users to hear the full message</td> </tr> <tr> <td>Applying style attributes for onFocus() dynamically</td> <td>Use :focus for the related elements in your CSS stylesheet</td> </tr> <tr> <td>Applying inline styles may cause user stylesheets to not be read properly</td> <td>Keep your styles in CSS files to keep the consistency of the theme</td> </tr> <tr> <td>Creating very large JavaScript files that slow down overall site performance</td> <td>Use less JavaScript; prefer CSS for animations or sticky navigation for better performance</td> </tr> </table></div> <h3> Fokusmanagement auf Komponentenebene </h3> <ul> <li>Wenn der Benutzer ein Modal öffnet, sollte er in der Lage sein, mit der Tabulatortaste zwischen den umsetzbaren Elementen darin zu navigieren (z. B. Schaltflächen „Abbrechen“ und „Senden“). Der Fokus muss jedoch auf das Modal beschränkt bleiben, um zu verhindern, dass der Benutzer auf Elemente außerhalb davon zugreift, es sei denn, er schließt das Modal explizit. Dadurch wird sichergestellt, dass der Fokus im Modal gefangen bleibt.</li> </ul> <h3> Fokusverwaltung auf Seitenebene </h3> <ul> <li><p>Der Fokus muss auch dann erhalten bleiben, wenn ein Benutzer von Seite zu Seite navigiert.</p></li> <li><p>Jedes Mal, wenn ein Benutzer auf einen Link klickt, um zu einer anderen Seite innerhalb der Anwendung zu gelangen, bleibt der Fokus entweder an derselben Stelle oder wird möglicherweise ganz woanders platziert.</p></li> <li><p>Hier sind die empfohlenen Fokuspositionen, wenn der Benutzer von einer Seite zur anderen navigiert.</p></li> <li><p>Konzentrieren Sie sich mit einer Arie-Live-Ansage auf den Hauptcontainer.</p></li> <li><p>Konzentrieren Sie sich wieder auf einen Link, um zum Hauptinhalt zu springen.</p></li> <li><p>Verschieben Sie den Fokus auf die Überschrift der obersten Ebene der neuen Seite.</p></li> </ul> <h3> Zustandsverwaltung auf Komponentenebene </h3> <ul> <li><p>Der Komponentenstatus sollte mithilfe von ARIA-Attributen verwaltet werden (verwenden Sie z. B. ein aria-expanded-Attribut, um dem Benutzer mitzuteilen, ob ein Dropdown-Menü oder eine Dropdown-Liste erweitert oder reduziert ist).</p></li> <li><p>Bei der Anwendung von ARIA-Attributen ist es wichtig, selektiv vorzugehen. Denken Sie über den Benutzerfluss nach, um zu verstehen, welche kritischen Informationen dem Benutzer übermittelt werden sollten.</p></li> </ul> <h3> Statusverwaltung auf Seitenebene </h3> <ul> <li><p>Wenn Inhalte auf der Seite dynamisch hinzugefügt oder aktualisiert werden (z. B. eine Warnmeldung oder Textänderung), sollte dies dem Benutzer angekündigt werden.</p></li> <li> <p>Besser verwenden </p> <ul> <li>Reagieren: React-Aria-Live oder React-A11y-Ansager </li> <li>Angular: LiveAnnouncer </li> <li>Vue: vue-a11y-utils </li> </ul> </li> </ul> <p>(weiter...)</p>
