Tagged: accessibility, av_tab_section, bfsg, eaa, form, screen-reader-response, tab, tabcontainer, tablist, tabpanel
-
AuthorPosts
-
April 24, 2024 at 4:04 pm #1440693
Hey guys!
We use the Enfold theme for our corporate website. As part of the approaching implementation of the European Accessibility Act (EAA), we tested our site for barriers. Some barriers were homemade, others were based on the semantics and role names used in the theme.
For example, for tabs, a role “tablist” is correctly defined on the div construct. The tab has the role “tab”. Unfortunately, the child, i.e. the actual content, is missing the “tabpanel” role. This fact is criticized during exams. Furthermore, also correctly, the id of the child to be controlled (tabpanel) is defined in the tab with aria-controls=id-des-child. Unfortunately, the child (tabpanel) itself is missing that it is described by the tab. So, on the one hand, the tab is missing the corresponding id (id=id-of-the-tab) and, on the other hand, the child (tabpanel) is missing an aria-labelledby=id-of-the-tab.
Another unpleasant barrier is the empty list
above any form. Notes are added to this list in the event of an incorrect form being sent. Without error, an empty list without child elements is detected and this is non-compliant. In case the empty list must remain, you should assign the attribute <ul aria-hidden=true> to the element. Then it is hidden in the accessibility tree. As soon as the list has a child, the value true should be changed to false.
In general, care should be taken in the theme to ensure that elements that are not used but are relevant to the structure of the page, such as headlines, lists, buttons, etc., are not kept as empty or placeholder elements for later dynamic processes. These elements can be accessed through assistive technologies (e.g. screen readers) and then cause confusion. If it cannot be implemented differently in the code, then the elements must be given the attribute aria-hidden=true and, depending on the element, also hidden in the tab navigation with tabindex=-1. For example, if you do not want to use the <h2> element (milestone date) in the theme content element “Timeline” for design reasons, the H2 is kept empty in the code as a placeholder <h2></h2>. A screen reader therefore reads an empty heading.
Can these barriers be resolved in a next update to the Enfold theme? Or what tools do I have to exclude or resolve the barriers in a roundabout way without creating cumbersome Javascript workarounds?
For your information, the test was carried out using the highly recommended plugin for checking accessibility (WCAG 2.2) from Eye-Able. The tool is called Audit.
Note: The two plugins “One click Accessibility” or “WP Accessibility” suggested in the theme extensions do not help.
Thank you for your feedback.
Best regards, Marko
April 30, 2024 at 8:41 pm #1441500Hey S24-Marketing,
Thank you for your patience, for the tab_content not having the tabpanel role, and to add the ID as aria-labelledby, please try adding this code to the end of your child theme functions.php file in Appearance ▸ Editor:function add_tabpanel_role_to_tab_content() { ?> <script> window.addEventListener('DOMContentLoaded', function() { (function ($) { $(".av_tab_section .tab_content").attr('role','tabpanel' ); $('.tab_content').each(function() { var id = $(this).attr('id'); $(this).attr('aria-labelledby', id); }); })(jQuery); }); </script> <?php } add_action('wp_footer', 'add_tabpanel_role_to_tab_content');
and then test the site and see if that corrects.
Best regards,
MikeMay 6, 2024 at 2:36 pm #1442444Hallo 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, MarkoMay 7, 2024 at 5:36 pm #1442590Hi,
Thanks for the feedback, I have shared this with the Dev Team for their review and will reply when I hear back from them. Thank you for your patience.Best regards,
MikeMay 8, 2024 at 7:29 pm #1442718Hi,
The Dev Team has modified the tab files to address this, below please find a zip file with three files, use them to replace your theme files after saving your current ones for roll back.
The files to replace are:
/enfold/config-templatebuilder/avia-shortcodes/tabs/tabs.js
/enfold/config-templatebuilder/avia-shortcodes/tabs/tabs.min.js
/enfold/config-templatebuilder/avia-shortcodes/tabs/tabs.php
after replacing these clear any cache plugins and your browser cache and disable Enfold Theme Options ▸ Performance ▸ JS & CSS file merging and compression and enable Enfold Theme Options ▸ Performance ▸ Delete old CSS and JS files
and then check, and let us know.Best regards,
MikeMay 13, 2024 at 4:33 pm #1443266Hi 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,
MarkoMay 14, 2024 at 11:30 am #1443403Hi,
I have passed this along to the Dev Team and will reply again when I hear back, thank you for your patience.Best regards,
MikeMay 14, 2024 at 3:57 pm #1443434Hi,
Please find the updaed files linked below, it fixes the three issues, the Dev Team adds an additional note for issue 3: use the enter to open tab content when tab has focus.Best regards,
MikeMay 15, 2024 at 1:58 pm #1443669Hi 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
May 18, 2024 at 3:09 pm #1444332 -
AuthorPosts
- You must be logged in to reply to this topic.