When using Tab List and Tab Content blocks together, Cwicly adds a ‘aria-controls’ attribute to each button. However, the attribute does not have a value set. This, I suspect, presents an accessibility problem because the cause (the button) and the effect (the content being revealed/hidden action) are not associated clearly.
The functionality is, I assume, controlled by the ordering of the respective button and content blocks rather than via their ID. Adding the content block ID to the aria-controls attribute of the associated button, I think, would resolve the accessibility issue. It may also need aria-labeledby to be added to the tab panel to give further feedback to the user.
Forgive me if I have misunderstood the accessibility approach. I’m not an expert in this area, but I have tested it using VoiceOver on Brave and there does seem to be a disconnect between the button and the panel.
There is provision for this in the Cwicly tabs logic but it looks like there is a bug or two currently preventing it from applying. The content block IDs should be forced and the aria-controls applied on page load.
We’ve reached out to a competent source to make sure that the aria-labelledby attribute for tabpanel should always link to the tab element that controls the panel.
The tablistaria-labelledby should be filled in by the user.
I’ll leave this in confirmed bugs until this segment is sorted.
Yes, my understanding would also be that the panel (Tab Contents) should have a aria-labelledby set to the corresponding tab. It doesn’t currently have this - even after the update - hence I asked the question!
