Kadence Theme not Accessibility Ready yet!

Hey,
Thanks for posting.

1. I’ll update the skip link to point to #main so it’s hitting the main region landmark.

2. Hmm I had a conversation with an accessibility expert on this and we didn’t come to any hard conclusions. It’s tricky scroll to the top takes the user to the top of the page from the bottom (after footer, not after content) focusing on the heading level 1 wouldn’t always do that, also focus on skip link would make it appear to visual users when you wouldn’t want that. I’m going to ask around more about this to see if anyone has a suggestion. Perhaps focusing on body tag would make sense because then the next thing would be the skip to content.

3. I’m not sure what you mean here. the theme has CSS to set the wordbreak to normal for tables

.entry-content table {
    word-break: normal;
}

Can you give me an example of what you would like to see or have changed? I just tested a table with Kadence and with Twenty-twenty-one and didn’t see any difference.

4. I believe the thought behind the way the navigation would work in the carousel is that you tab into the carousel navigation element, from there the arrow keys move the navigation thus you don’t tab directly into the buttons. Did it not work this way for you?

Ben

Hello Ben,
Thank you for the quick response,
I am a certified professional in web accessibility, I help businesses with WCAG compliance. I have been a accessibility specialist for 15years & I am also legally blind. I rely on screen readers every day.
Scroll to top should either move the focus to H1 of the page, logo or the skip link. We cannot focus on the document region before the skip link.. this will not be announced.
NVDA Screen reader when focused on the div of the document announces as document region & read the page title which confuses the user.
Ok, here is the analysis of the code for similar posts.
<div class=”tns-controls” aria-label=”Carousel Navigation” tabindex=”0″><button type=”button” data-controls=”prev” tabindex=”-1″ aria-controls=”tns1″>prev</button><button type=”button” data-controls=”next” tabindex=”-1″ aria-controls=”tns1″>next</button></div>

This code here <div class=”tns-controls” aria-label=”Carousel Navigation” tabindex=”0> bring the focus to the div tag,, this is not recommended.
><button type=”button” data-controls=”prev” tabindex=”-1″ aria-controls=”tns1″>prev</button><button type=”button” data-controls=”next” tabindex=”-1″ aria-controls=”tns1″>next</button></div>
The <button>do not need tabindex=-1. These buttons are focusable by keyboard as they are HTML elements.
To answer your comment here,
4. I believe the thought behind the way the navigation would work in the carousel is that you tab into the carousel navigation element, from there the arrow keys move the navigation thus you don’t tab directly into the buttons. Did it not work this way for you?
The focus of screen reader does not move into forms/focus mode directly when it is encountering the previous & next buttons. By removing the tabindex=0 on the div tag & removing tabindex=-1 on buttons will solve this, this is also the expected behavior.

Regarding Tables, I will get back once I talk to my sighted assistance.

Thanks!

Hey,
Regarding #2 I’m getting conflicting opinions on this from different experts. They all say I should change how it currently works (which currently the focus is removed through blur leaving you in the document).

But two now are saying I should move it to the body tag. It’s interesting that you keep saying it should be moved to the skip link. Do you have any websites you are aware of that are currently doing this, I would like to see how it’s being handled.

Regarding #4 I think I’m missing you here. The tabindex=-1 is added to the buttons on purpose. It makes it so the user tabs to the controls div with the aria-label=”Carousel Navigation”. While on this div the arrow keys work to move the carousel in either direction. If you tab into the buttons themselves you would then have to “press” to move in one direction and tab through the other to move in that direction.

By the way, this system isn’t Kadence specific at all, we didn’t write that javascript which powers the carousel it’s a popular js library that has it designed this way.

I do understand that generally you don’t want to make a div focusable but in this context where a label is provided it at least makes sense to me as a better way to navigate the carousel vs having to tab into each button.

I’m going to look around to see if I can find some examples of best practices with carousels like this. If you have any links that point to making the arrows the focusable items please post them here so I can play around with how that works.

Thanks for engaging, I’m always looking for ways to improve accessibility where I can.

Ben

Hello Ben,
If you can fix the skip link immediately that will be helpful. I am doing a video of all the accessibility problems I am running with Kadence & will send it across. The scroll to top either can move to skip link or heading level1. Instead of doing nothing currently we prefer it doing something.

The table of content is also broken. Currently they do not move focus to headings in posts or pages. Like skip link.

There is a weird problem with menus when there are child menus screen reader has problem. For example, on my site when it encounters resources expand child menu. That hint is wrong, resources is a link & should be announced as resources link.
The child menu button is announced as child menu button link. It should state resources child menu button or child menu for resources button. It cannot say button link. That is like announcing dual role which is button & link.

I will be doing a detailed video of these things. Let me know if I need to send it to a specific email. I would like to work & see if we can resolve these small hick-ups & make Kadence the best in accessibility.

Thanks!
my site is
https://www.digitala11y.com

Hi,

Thanks for posting.

There is an update for the theme. I fixed the skip link and made some changes.

Scroll to top puts the focus on the body, again this was consistently what other accessibility experts said to do. I mentioned this before and was just hoping you could follow up on this exact part of my previous message: “It’s interesting that you keep saying it should be moved to the skip link. Do you have any websites you are aware of that are currently doing this, I would like to see how it’s being handled.”

I think I see what the issue is with the screen reader reading the toggle label instead of the active link, I’m working on a fix for this.

The table of contents block has an update coming out soon that will fix this. It has to do with the smooth scroll effect.

Ben

Hello,
Thanks for the update. This really helps, the fix is working. I made a video for the scroll to top & the carousel
https://www.dropbox.com/s/diqw5rdigxehi9f/accesssibility%20problems%20on%20kadence.mp4?dl=0

I am not sure if the accessibility specialists who said it needs to go to body tag are people with disability. when it goes to body/document region the screen reader doesn’t announce anything. I demonstrated it in video.
Let me know if i can be of any help.

Hi,
Thanks for taking the time to create a video!

I think we are missing each other with regard to the Scroll to top. I understand that you want some kind of an announcement for the screen reader that the scroll to top worked when enter was pressed on the scroll to top button. I can’t find any context for this or examples on other sites doing what you are suggesting. Do you have any websites you are aware of that are currently doing this? I want to make it clear that it doesn’t make any visual sense to focus on the skip content button since that will make it appear to all visual users and the button is a scroll to top button not a scroll to skip content link button. Hopefully that clarifies. If you have some context from other sites that do this then I can see what method they use to prevent it from breaking for all visual users.

Regarding the pagination navigation. It’s odd that your screen reader isn’t picking up the SVG arrow title which is there specifically for accessibility purposes. That title is set to next. I’m going to run some tests but perhaps I just add screen reader text instead of trusting it to read the SVG title.

As for filtering this yourself, it’s using the WordPress core function the_posts_pagination so you can change how core outputs pagination.

The menu will get fixed with the next version of the theme.

Again it’s odd your screen reader isn’t reading the Aria label for the navigation on the carousel. Instead, it seems to be reading an internal button that doesn’t even have the focus. Really odd. I’m trying to see what I can come up with. The screen reader just needs to read the aria-label and it would all make sense that you can navigate with arrow keys.

Ben

Hello,
Here is thee working example of carousel,
https://www.w3.org/TR/wai-aria-practices-1.1/examples/carousel/carousel-1.html
And also the breadcrumbs need bit of accessible markup,
https://www.w3.org/TR/wai-aria-practices/examples/breadcrumb/index.html
currently the breadcrumb is not inside a landmark region & no aria-current.

The SVG title is not picked because screen readers have very limited capability for now to identify & provide right information . using aria-label on it will solve this.
https://www.deque.com/blog/creating-accessible-svgs/
Regarding to scroll to top I will find some information & get back. But as I have shown in video it is not helping blind people like me.
Fixing your current carousel, yes the aria-label is there but the problem is the screen reader doesn’t move into forms/focus mode. As a result I cannot use arrow keys. To fix this on the div that has aria-label & tabindex=0 use the role=toolbar. Here is the example
https://www.w3.org/TR/wai-aria-practices/examples/toolbar/toolbar.html

I hope this is helpful. Let me know if any more information is needed.

Hello,
here is the example of scroll to top moving to skip link or to first link in page.
https://www.deque.com/company/careers/accessibility-consultant/#page-top
in the above job posting skip to top link moves to skip link.
https://www.cariefisher.com
the back to top link moves to homme link.

I hope these examples are good. Deque is considered as leader in accessibility.

Hey,
Thanks for posting.

Deque is using an empty anchor tag.

<a id="page-top"></a>

That is placed at the top of their HTML, just after the opening to the body tag. I’m not sure I understand why that would be more accessible than focusing on the body tag the result is the same, the focus is moved to the top of the page on an element that doesn’t do anything. You tab once from there and you get the skip link, which is the same as with Kadence. You wrote that in the link you added it takes you to the skip link, however that doesn’t happen to me when I use keyboard navigation.

In the Carieshisher site the scroll to top moves you to the id=’header’ which is just the site header tag element in the page. However, it’s similar to the body tag in that it’s just a dom element that doesn’t do anything when you focus on it. And importantly the Carieshisher site doesn’t seem to provide a skip to content link? so moving focus to the header tag works whereas in many sites it wouldn’t because you would be moving it past the skip to content link. Again I have to tab again to reach the menu. You seem to be saying that you don’t have to tab again? Are we seeing these differently?

Ben

Hello ben,
Here is a poll I ran & majority of the accessibility community agrees that it should go to skip link. For me as screen reader user both deque & cariefisher.com NVDA reads the links & the feedback I get is good enough.
https://www.digitala11y.com/scroll-to-top-where-should-the-focus-land/
https://www.linkedin.com/posts/raghavasatish_accessibility-a11y-question-activity-6867327293543526400-myr0/

Thanks, this has created a lot of internal conversation as we try to figure out how to both provide a better experience for screen readers and not hurt and confuse the experience for visual users. We are working on a solution.

Ben

Hey, just wanted to follow up on the theme update that went live just now should resolve most things you brought up.

Ben

Hi, Thanks for fixing the accessibility issues. Really appreciate the prompt response,
i see the following failure from Axe chrome extension,

Issue Description
Ensures links have discernible text
Element location
#kt-scroll-up
Element source
<a id="kt-scroll-up" tabindex="-1" href="#wrapper" class="kadence-scroll-to-top scroll-up-wrap scroll-ignore scroll-up-side-right scroll-up-style-outline vs-lg-true vs-md-true vs-sm-false">
To solve this issue, you need to...
Fix at least one (1) of these issues:
? 
Element does not have text that is visible to screen readers
? 
aria-label attribute does not exist or is empty
? 
aria-labelledby attribute does not exist, references elements that do not exist or references elements that are empty
?

i believe there is a Icon or something before the button tag that needs hiding from screen reader. i see the tabindex=-1, we need to provide aria-hidden=true for it. so it will not appear in DOM. currently screen reader identifies this element when using arrow key navigation.

Hello,
Here are the bugs that need fixing for next update,
In the related post carousel the following code got tablist, this need to be toolbar. tablist role is used for tabs & the child roles are missing. Use axe chrome extension to find the accessibility bug.
<div class=”tns-nav” role=”tablist” aria-label=”Carousel Pagination”><button type=”button” data-nav=”0″ aria-controls=”tns1″ style=”” aria-label=”Carousel Page 1″ class=”” tabindex=”-1″></button><button type=”button” data-nav=”1″ tabindex=”-1″ aria-controls=”tns1″ style=”” aria-label=”Carousel Page 2″></button><button type=”button” data-nav=”2″ aria-controls=”tns1″ style=”” aria-label=”Carousel Page 3 (Current Slide)” class=”tns-nav-active”></button><button type=”button” data-nav=”3″ tabindex=”-1″ aria-controls=”tns1″ style=”display:none” aria-label=”Carousel Page 4″></button><button type=”button” data-nav=”4″ tabindex=”-1″ aria-controls=”tns1″ style=”display:none” aria-label=”Carousel Page 5″></button><button type=”button” data-nav=”5″ tabindex=”-1″ aria-controls=”tns1″ style=”display:none” aria-label=”Carousel Page 6″></button></div>

There are two scroll to top elements exposing to screen reader the button tag is in tab navigation & the tag that has tabindex=-1 is coming in readeing order while using arrow keys. The tag need to be removed from DOM & only the button tag should be exposed.

If these are fixed I believe we fixed all failures. There are best practices, I can provide the best practices & developers can fix if they have time.