Forum Replies Created
-
Posts
-
Hi Mike!
Thanks for the adjustments. With this version, the tabs function correctly, are accessible and usable and do not cause errors in the WCAG testing tool Eye-Able-Audit. That’s great! Thank you for your commitment and the commitment of your team!
Are you interested in further optimizing your theme? I noticed other little things that are not optimal in terms of accessibility.
1. For example, in the “Timeline” content element. If no entry is added to the “Milestone Date” field, an empty <h2> tag is output in the HTML code. Headlines can be filtered through screen readers and output as a navigable list. An empty headline tag would not be optimal in this case. The solution here is to assign the attribute aria-hidden=”true” and tabindex=-1 to an empty <h> tag.
2. In the navigation menu, the links to the individual pages are determined by the accessible content of the tag and output by screen readers. If a navigation point is implemented without textual content but only with an icon, the accessible content of the link is missing. In this case, an optional title attribute can be assigned to the link with icon. However, a title attribute is not reliably viewed by screen readers as an accessible name for a link. In this case you need a way to optionally enter an “aria-label=name of the link”.
I would like to thank you for your effort and the super-fast support!
Best regards, Marko
—
Hallo Mike!
Danke für die Anpassungen. Mit dieser Version funktionieren die Tabs korrekt, sind zugänglich und bedienbar und verursachen keine Fehler im WCAG-Prüftool Eye-Able-Audit. Das ist Klasse! Vielen Dank für deinen Einsatz bzw. den Einsatz eures Teams!
Seid Ihr interessiert an weiteren Optimierungen eures Themes? Ich habe weitere Kleinigkeiten festgestellt, die hinsichtlich der Barrierefreiheit nicht optimal sind.
1. Beispielsweise im Inhalts-Element “Zeitleiste”. Wird im Feld “Meilenstein-Datum” kein Eintrag hinzugefügt, dann wird im HTML-Code ein leeres <h2>-Tag ausgegeben. Headlines können durch Screenreader gefiltert und als navigierbare Liste ausgegeben werden. Ein leeres Headline-Tag wäre in diesem Fall nicht optimal. Die Lösung an der Stelle ist, einem leeren <h>-Tag das Attribut aria-hidden=”true” und tabindex=-1 zuzuweisen.
2. Im Navigationsmenü werden die Verlinkungen zu den einzelnen Seiten durch den zugänglichen Inhalt des -Tags bestimmt und durch Screenreader ausgegeben. Wird ein Navigationspunkt ohne textlichen Inhalt, sondern nur mit einem Icon umgesetzt, fehlt der zugängliche Inhalt des Links. In diesem Fall kann ein optionales title-Attribut dem Link mit Icon zugewiesen werden. Ein title-Attribut wird jedoch nicht zuverlässig von Screenreadern als zugänglicher Name für eine Verlinkung angesehen. In diesem Fall benötigt man eine Möglichkeit ein “aria-label=Name des Links” optional eintragen zu können.
Ich bedanke mich für eure Mühe und den superschnellen Support!
Beste Grüße, Marko
Hi Mike!
It’s really great that the adjustments will be included in a later update!
This makes the snippet you previously provided obsolete, right?However, there are still small adjustments:
1. The tablist role must be one level deeper, namely on the div element with the class tab_titles. This is the div element that contains all tabs.
2. Selected, active tabs must receive the attribute aria-selected=true. Unselected, inactive tabs must receive aria-selected=false. Since no aria-selected is currently defined in advance when loading the page, all tabs are considered selected according to the screen reader NVDA. That is very confusing. Unfortunately, the tabs only get the correct status after these tabs have been clicked at least once.
3. Tabs that have already been clicked receive the attribute tabindex=-1. This means that once you have selected tabs, you cannot access them again using the Tab key, as these tabs are removed from the navigation tree. Tabindex=0 should be kept.I can then test the functionality again.
Thanks and best regards,
Marko—
Hallo Mike!
Echt toll, dass die Anpassungen in einem späteren Update enthalten sein werden!
Das Snippet, welches du zuvor zur Verfügung gestellt hattest, wird dadurch obsolet oder?Es gibt jedoch noch kleine Anpassungen:
1. Die Rolle tablist muss eine Ebene tiefer und zwar auf das Div-Element mit der Klasse tab_titles. Das ist das Div-Element, welches alle Tabs beinhaltet.
2. Ausgewählte, aktive Tabs müssen das Attribut aria-selected=true erhalten. Nicht ausgewählte, inaktive Tabs müssen aria-selected=false erhalten. Da aktuell beim Laden der Seite kein aria-selected im voraus definiert ist, werden laut dem Screenreader NVDA alle Tab als ausgewählt gewertet. Das ist sehr verwirrend. Leider erhalten die Tabs erst dann den korrekten Status, nachdem diese Tabs mindestens ein Mal geklickt wurden.
3. Bereits geklickte Tabs erhalten das Attribut tabindex=-1. Hierdurch können einmal ausgewählte Tabs nicht wieder mit der Tab-Taste erreicht werden, da diese Tabs dem Navigationsbaum entzogen werden. Es sollte tabindex=0 beibehalten werden.Anschließend kann ich gerne die Funktionalität erneut testen.
Vielen Dank und beste Grüße,
MarkoHallo Mike!
Danke für deine schnelle Antwort und den Lösungsansatz.
Leider ist dieser nur halb korrekt.
Das Element mit der Rolle “tabpanel” wird vom Element mit der Rolle “tab” gelabelt und nicht von sich selbst.
Entsprechend muss zunächst das Element mit der Rolle “tab” eine eigene ID erhalten. Zum Beispiel den Wert des Attributs data-fake-id ohne das Rautezeichen.
Jedes Element mit der Rolle “tabpanel” erhält das Attribut aria-labelledby, welches den Wert mit dem Bezug auf die ID des Elementes mit der Rolle “tab” erhält.
Außerdem, und das hatte ich in meiner Anfrage zuletzt vergessen, erhält das aktive Element mit der Rolle “tab” das Attribut aria-selected=true.
Alle nicht aktiven Tabs erhalten das Attribut aria-selected=false oder erhalten kein entsprechendes Attribut.
Die Zusammenhänge werden hier noch einmal deutlich erläutert: https://www.w3.org/WAI/ARIA/apg/patterns/tabs/
Hier ist ein Beispielaufbau eines Tablisten-Konstruktion mit WAI-Aria: https://www.w3.org/WAI/ARIA/apg/patterns/tabs/examples/tabs-manual/Es wäre wirklich sehr nett, wenn diese Anpassung am Template vorgenommen bzw. das Javascript dahingehend angepasst werden könnte.
Gibt es auch eine Lösung für die eingangs beschriebene leere Liste
oberhalb von Formularfeldern?
Vielen Dank für deine Unterstützung!
Beste Grüße, Marko—
Hi Mike!
Thank you for your quick answer and the solution.
Unfortunately, this is only half correct.
The element with the role “tabpanel” is labeled by the element with the role “tab” and not by itself.
Accordingly, the element with the role “tab” must first receive its own ID. For example, the value of the data-fake-id attribute without the hash sign.
Each element with the role “tabpanel” receives the attribute aria-labelledby, which receives the value with reference to the ID of the element with the role “tab”.
In addition, and I forgot this in my last request, the active element with the role “tab” receives the attribute aria-selected=true.
All inactive tabs receive the attribute aria-selected=false or do not receive a corresponding attribute.
The connections are clearly explained again here: https://www.w3.org/WAI/ARIA/apg/patterns/tabs/
Here is an example tab list construction with WAI-Aria: https://www.w3.org/WAI/ARIA/apg/patterns/tabs/examples/tabs-manual/It would be really nice if this adjustment could be made to the template or the Javascript could be adapted accordingly.
Is there also a solution for the empty list
above form fields described at the beginning?
Many thanks for your support!
Best regards, Marko
