Sind Tastaturkürzel für 508 Compliance erforderlich?

Question

Ich recherchierte viel darüber und scheint zu widersprüchliche Antworten auf SO und das gesamte Web zu bekommen. Ich verstehe, dass Übereinstimmung mit Section 508 NICHT gleich der Barrierefreiheit ist.

Größte Sache ist, dass der UI/UX-Designer gesagt wird, dass Tastaturkürzel für das Dropdown-Menü benötigt, um Tastaturkürzel zu haben, um 508-konform zu sein. Ich sehe Windows Forms-Anwendungen diese haben, aber für Web-Entwicklung Ich glaube nicht, dass zwingend „compliant“

Meine andere Frage zu sein, die beantwortet wurde, ist hier: MVC 4 site 508 compliant

Answer 1

stimme ich teilweise mit Thinice, aber stimme mit den ersten beiden Sätzen des Kommentars gelassen.

Die Sätze, die ich mich beziehe, sind:

Sie sollten für 508 von Tastatur -reachable- werden.Ich Betonung zwischen einer Verknüpfung auf dem Unterschied zu erhalten und ist erreichbar

Crixus sagte:

größte Sache ist, dass die UI/UX Designer Verknüpfungen, die Tastatur erzählt wird für das Drop-Down-Menü Bedürfnisse haben Tastaturkürzel, um 508 kompatibel zu sein.

Sie müssen dies klären. Meinst du eine einfache <select> oder ein Dropdown für ein Navigationsmenü? Wie Thinice in Kommentaren feststellte, muss Abschnitt 508 nur sagen, dass er erreichbar sein muss. Die Frage wird:

wie fügen Sie Tastenkombinationen zu Ihrer Anwendung hinzu? Fügen Sie sie über das Attribut accesskeys hinzu oder wie fügt Google Mail Shortcut Keys hinzu?

Ich dachte, ich habe eine Antwort über AccessKeys, kann aber nicht finden. Im Wesentlichen klingt Accesskeys wie eine großartige Sache, aber wenn Sie die Schlüssel betrachten, die Sie verwenden dürfen, die sich weder mit Browsern noch mit Schlüsseln der Unterstützungstechnologie befassen, sind Sie ziemlich begrenzt. Gez Zitrone tat an overview of AccessKeys, and their issues. Wenn Sie den Yahoo! Mail-Ansatz verwenden möchten, müssen Sie ein bisschen mehr arbeiten. Todd Kloots machte eine presentation about ARIA, die hilfreich sein kann. Was mich in den zweiten Teil führt. Wenn Sie JavaScript stark auf einer Website verwenden, um Dinge zu tun, verwenden Menschen sowohl 1194.21 (Softwareanwendung/OS) und 1194.22 (Web) Standards, um eine Website zu bewerten. Wenn die Site JS zum Erstellen eines navmenu verwendet (YUI menu example), muss das Dropdown-Verhalten über die Tastatur erreichbar sein. Ich würde sagen, das fällt unter:

§ 1194.21 Softwareanwendungen und Betriebssysteme.
(a) Wenn Software auf einem System mit einer Tastatur ausgeführt werden soll, müssen Produktfunktionen über eine Tastatur ausführbar sein, wobei die Funktion selbst oder das Ergebnis der Ausführung einer Funktion im Text erkannt werden kann.

UND

(c) Eine gut definierte Bildschirm-Anzeige des aktuellen Schwerpunkt vorzusehen, der als der Eingabefokus unter den Änderungen der interaktiven Oberflächenelemente bewegt. Der Fokus soll programmatisch herausgestellt werden, so dass unterstützende Technologie Fokus- und Fokusänderungen verfolgen kann.

Ich sage, dass beide Standards verwendet werden, weil (a) besagt, dass man über die Tastatur in den Navigationsbereich gelangen kann. (c) kommt ins Spiel, weil einige Menüs Tab zu allen übergeordneten Elementen können, aber Sie können nicht in den Dropdown-Teil ohne eine Maus gelangen. Ich habe Menüs gesehen, die Sie Tab zu den Untermenüpunkten haben können, aber das Menü öffnet sich nicht. Also, wenn Sie nur die Tastatur (Mobilität imparments) verwenden, im Gegensatz zu JAWS, werden Sie keine Ahnung haben, wo Sie sind.

Ich sehe Windows Forms diese Anwendungen haben, aber für I Webentwicklung glaube nicht, dass zwingend "compliant"

Ich würde sagen, tatsächliche Anwendungen zu sein, wie Word, Outlook, etc. Liefern Sie Verknüpfungen zu häufig verwendeten Befehlen.Wenn Sie dies für eine Webanwendung tun, würde ich darüber nachdenken, wie viele Sie tun. Dies ist kein obligatorisches Teil, um konform zu sein. Wenn Sie eine Navigationsleiste erstellen, würde ich die Verwendung von ARIA roles, insbesondere role="navigation", für das Elternelement als bewährte Methode empfehlen.

Answer 2

Das Problem mit einigen Standards (wie auch wie viele Gesetze) sind, dass sie offen für Interpretationen sind ...

Die einzige Erwähnung ich in den 508-Standards finden kann, die Tastatur verwenden erwähnt is this (wörtlich):

Abschnitt B - Technische Normen

§ 1194.21 Softwareanwendungen und Betriebssysteme.

(a), wenn die Software ausgelegt ist, auf einem System zu laufen, das eine Tastatur hat, die Produktfunktionen werden von einer Tastatur ausführbar sein, wo die Funktion selbst oder das Ergebnis eine Funktion ausführen kann textuell erkennbar.

Mein Spin hierzu:

• Eine Tastatur Abkürzung für Navigationsoptionen kann ein gegebener Abschnitt angesichts der Menge von Operationen/Funktionen enthalten kann unpraktisch sein. Es ist wichtig, dass sie per Tastatur erreichbar sind.
• Von einem UX-Standpunkt aus sollten Schlüsselfunktionen Abkürzungen haben "nur weil" es eine gute UX-Übung ist. Aber zur Abkürzung geht alles von einem Graben in den anderen.
• 508! = Erreichbarkeit, aber wenn Sie für ein Gov/Edu arbeiten, ist es wahrscheinlich in Ihrer PD konform zu sein.

Das andere Ende des Spektrums ist die WCAG die so ziemlich mit 508 Compliance und in meinem Buch besser definiert gekoppelt ist: Keyboard stuff is under 'operable' in WCAG.

Auf den Punkt gebracht: Es ist eine gute Übung für UX benutzerdefinierte Tastenkombinationen haben für wichtige Funktionen. Hat aber selbst keine Auswirkung auf die Einhaltung von 508. (Mit der Ausnahme, dass Funktionalität per Tastatur erreichbar sein sollte - irgendwie).

Answer 3

Es gibt ein gewisses Maß an Konformität mit 508, wenn Sie von einem Regierungsprojekt sprechen. Manche Abteilungen vergeben 508 Punkte an ihre Entwickler, und sie berücksichtigen Ihre Punktzahl für zukünftige Verträge. 508 Compliance erfordert nur, dass alles per Tastatur erreichbar ist, was in der Regel richtig ist. Bildschirmleser lesen alles, was nicht ausgeblendet ist, und Tabtasten führen Personen durch Links. Aber wenn Sie ein gutes Ergebnis wollen, müssen Sie die Absicht und nicht nur den Buchstaben des Gesetzes ansprechen.

Bearbeiten: Bildschirmleser werden einige versteckte Elemente lesen. Eine Methode besteht darin, einen Artikel absolut über dem Bildschirm mit einer negativen oberen Position zu positionieren. Eine andere Möglichkeit ist die Verwendung der Clip-Eigenschaft. http://adaptivethemes.com/using-css-clip-as-an-accessible-method-of-hiding-content/ Aber wenn Sie display: none, Höhen von Null und Javascript toggelt, sprechen viele Bildschirmleser diese Elemente nicht.

Im Fall einer Dropdown-Liste verbergen Sie aktiv Elemente aus Bildschirmleseprogrammen usw. Sie müssen es also korrigieren, da die meisten Leser keine Anzeige hören werden: keine.

Sie werden keine definitive Dokumentation zur Tastaturnavigation finden. Der Grund niemand angeben wird genau das, was zu tun ist, dass es so viele potenzielle Konflikte sind - mit dem Browser, das Betriebssystem, etc. Es gibt auch keine Standards, obwohl Aria macht Fortschritte: http://www.w3.org/TR/wai-aria-practices/#keyboard

Ich würde nicht Setzen Sie accessKeys auf ein Menü, wenn Sie das wollten.
Stattdessen siehe: http://www.w3.org/TR/wai-aria-practices/#aria_ex_widget

Ich würde tatsächliche AccessKeys für wichtige Dinge wie "Search" und "Home" speichern. Das Hinzufügen einer Lernkurve zu Ihrer Site würde die Ursache nicht verbessern, wenn Sie einen accessKey für alles hätten. Wenn Sie zum Beispiel "Über uns" accessKey = A eingeben und Ihnen 20 accessKeys zugewiesen sind, wäre das schlecht.

Ich habe 508 Seiten für eine lange Zeit gemacht, und persönlich, verwende ich nur Drop-Downs. Es ist viel einfacher, Unterseitenmenüs hinzuzufügen. Und ich persönlich hasse es, auf Dropdowns zu klicken. Drop-downs erfordern eine Genauigkeit beim Klicken, die mich nur irritiert und nicht bei der Barrierefreiheit hilft, da sich die Barrierefreiheit auch an Personen hält, die nicht gut klicken. Darüber hinaus sind Dropdown-Listen in der Anzahl der Ebenen begrenzt, die Sie haben können, nicht technisch, sondern von einer UX-Ansicht aus.

Was ich benutze:

• Tab-Indizes.
• Sorgfältig platzierte Menüs, so dass ein Benutzer keine große Liste von Links erhalten wird, bevor er die Grundidee der Website oder Seite hört.
• Bei einigen Projekten, Baummenüs mit übereinstimmender Pfeil-Tasten-Seitennavigation, sequenziell.
• Accesskeys H für Home und S für Suche, falls erforderlich.

Das Problem besteht vor allem in der Sortierung von Informationen. Denke darüber nach, wie schnell du eine lange Liste von Links durchsuchst, und stelle dir dann vor, wie du dort sitzt und darauf wartest, dass es dir vorgelesen wird. Organisieren Sie Ihren Inhalt vielleicht in verdauliche Stücke & lassen Sie das Suchfeld das Scannen durchführen. Hängt vom Inhalt ab.

Glück.:)