ROLE values not valid and ARIA attribute mismatch in Slider element

Community resources Bugs
1

Hello everyone,

I’m trying to optimize my website for SEO and Page Speed and Accessibility.
I ran Lighthouse test and encountered some problems with slider elements that weren’t present before. Don’t know if something has changed on Webflow’s side, or on Lighthouse’s side, but I’m trying to find a solution to it. It could be something on my end, but I really don’t think so because I haven’t changed anything and these issues were not detected before.

The SEO results also shows that the Slide Nav Dots overlap with each other and that they should be bigger:

clickable-elements-too-small
clickable-elements-too-small1193×596 74.1 KB

Of course I could solve this by giving those elements a 48x48 px size, but they are not entended to be used as buttons, but as an aesthetic guide.
The distance issue is with the standard 3 px spacing. A workaround is setting it to 7 px. Anything below that will trigger the error. It works, but ruins the design, so it’s not an ideal solution.

On the other hand, these two new ARIA errors popped up, which also weren’t shown before. One is regarding the Slider element [role] attribute:

role-values-not-valid
role-values-not-valid861×603 83 KB

I searched the WAI-ARIA role definitions website and found that "section" is an abstract role and shouldn’t be used in content:

role-section
role-section820×183 16.6 KB

Don’t really know what that means, or if that is the issue. But can’t think of anything else. I don’t know how to change the role to try something else.

Then I also got an [aria-*] attribute error, saying it’s value doesn’t match its role. This error applies, once again, to the Slider’s Nav Dots:

aria-attribute-mismatch
aria-attribute-mismatch917×606 76.3 KB

I referred to the WAI-ARIA role definitions website one more time and found that aria-selected doesn’t seem to be a valid attribute for the button role. Instead it should be aria-pressed.

Again, I don’t know how to change the role or aria attributes and values. But to be honest, even if I did, I think these things should be set properly by default.

I am not a web designer and have no experience with coding. This is my first website, so troubleshooting these kind of things is very time consuming for me. I am leaning a LOT in the process, but I still think the point of using a service like Webflow is to avoid all these problems.

Any help or advice is very much appreciated!

Here is my site Read-Only: LINK
And here is my published website, incase anyone wants to run the Lighthouse test: https://www.estanciaharberton.com/

1 Like
2

@forresto, @magicmark, @cyberdave, I am so sorry to mention you, but you are the guys I’ve seen replying to similar topics before.

If anyone from Webflow’s Staff could give some sort of feedback on this it would be great. At leas a “This is issue but there’s nothing you can do about it, so no point in stressing over it” would be nice.

Thanks in advance.

3

Bumping this thread.

Does anyone know how to fix this ARIA role Accessibility issue?

image
image739×314 18 KB

1 Like
4

I went down the same path as you (i.e. I read some of the ARIA specifications), and my guess is the same as yours (might be an issue where Webflow is coding the circular slider dot with an attribute of aria-selected instead of aria-pressed). This is just an educated guess though.

I tried the following:

  • Clicked the slider nav
  • Added a custom attribute for aria-pressed:

image

However, this places the attribute on the div that contains the slider dots, not on the slider dots themselves (i.e. in the screenshot below, I think we want the attribute to appear in the divs with the arrows):

image

I suppose further testing could be done with a script that adds the aria-pressed attribute to the divs that render the slider dots. Not a great solution, but it might help understand if that attribute is the cause. And if this is the issue, I agree that Webflow’s rendering of the code could be improved, in which case it’s likely worth adding a feature/bug request.

5

@VinM Hmmm, ok, here is the thing. Webflow’s native ROLE definition causes this problem. It adds attributes to the slider automatically.

role=“section” and aria-label=“carousel”

So what I did is removing those attributes with jQuery (set ID to your slider first)

image

It fixes the Lighthouse error msg and improved Accessibility number.

image

But again, I do not know what those ROLE/ARIA attributes are, and I am convinced that the Webflow dev team knows what they are doing. I can’t tell what is worse for SEO. If missing attributes or attributes with the error message in Lighthouse :smiley: At least we have better numbers for the EGO point of view.

1 Like
6

@tomasmarek I hear you on the role = “section” issue. What I shared in my last post was focusing on the role = “button” issue. I hadn’t really looked at the former too closely.

I can see how removing the attributes in jQuery might help improve the Lighthouse score, but the page accessibility is likely lower without the attributes. (I can’t tell if the SEO impact is better or worse.)

It seems like the optimal approach would be to keep the attributes and have them follow the ARIA specification, but I realize that the issues stem from the code that Webflow is natively producing (i.e. not your HTML). I’m sure the Webflow team knows far more about this than I do, but it’s still surprising that the resulting HTML is raising these flags.

7

I couldn’t believe I was the only person having this issue. Glad to see it wasn’t me messing things up.

I thought of doing this as well but, as you explained, we don’t have access to the dot elements themselves, therefore can’t think of a way to edit their properties without more complex custom code.

role and aria attributes serve to indicate screen readers what the actual content on the screen is. For example, an role="button" with an aria-label="show slide 2" and aria-pressed="false" will let a blind person know that such element is a button that, if selected, will show the slide 2. Changing aria aria-pressed="false" to aria-pressed="true" would let the blind person that he has currently pressed the button, therefore he is displaying slide 2.

I am not a web developer and this is actually my first website, so anything that I say could be wrong. However, I thing I can answer both of you and say that, based on the research I did, google ignores incorrect or mismatched role and aria attributes. Therefore, having them set incorrectly will affect Lighthouse results negatively, but the actual accessibility functionality would remain the same because google was ignoring them anyway.

At about the same time I noticed this error, I also found this post where @forresto said they have been making changes to Slider in the past week, in order to improve accessibility, which makes me suspect it is where all this came from.

Hope to here from some member of the Webflow Staff soon.

9

So, little update:

It seems the team has solved the role=section attribute error, however the other two errors are still present, both related to Slider’s Nav Dots.

These have an aria label to indicate the state of the button called aria-selected, but it should actually be aria-pressed, according to WAI-ARIA role definitions.

The Nav Dots overlapping problem is still there too.

Would be nice to hear back from one of the devs or know if anyone else is facing the same problems.

1 Like
10

Shame to see the dev team has enough time to break things but not enough time to fix them… Specially when the fix is so simple.

Pretty disappointed… :confused:

1 Like
11

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.

12

Hey folks – wanted to let you know that we’ve fixed this issue, all you have to do is republish your site for the fix to take effect. Thank you for your patience and care – let us know if you have any issues.

2 Likes
14

Hello Monica, thank you for letting us know about the fix.

I republished my website and indeed, the aria problem was fixed, but the slider dot size problem mentioned in the first post remains for mobile websites. It would be great if you guys could have a look at it.

Best wishes,
Thomas

15

Thanks for confirming @TomiLynch! We’ll look into prioritizing the slider dot problem for mobile.

16

I want to acknowledge and apologize that we didn’t take accessibility in mind when we originally made these elements, so yes fixing some of the accessibility issues can be difficult. We will be correcting this in any new elements we introduce.

As far as the slider dots, they are intended to be used as buttons. Unfortunately there really is no way, without complex custom code, to make them merely decorative at this point.

Yes, at this time the best way to style the dots is by setting the Slide Nav elements font size. If you want to edit the spacing for different screen sizes you can use this custom CSS code in the “Inside <head> tag” part of the page’s settings.

(Feel free to customize it to fit your spacing needs.)

<style>
/* Desktops */
@media screen and (min-width: 992px) {
  .w-slider-dot {
    margin-left: 12px !important;
    margin-right: 12px !important;
  }
}
/* Tablet portrait and down */
@media screen and (max-width: 991px) {
  .w-slider-dot {
    margin-left: 10px !important;
    margin-right: 10px !important;
  }
}
/* Phone landscape and down */
@media screen and (max-width: 767px) {
  .w-slider-dot {
    margin-left: 8px !important;
    margin-right: 8px !important;
  }
}
/* Phone portrait and down */
@media screen and (max-width: 480px) {
  .w-slider-dot {
    margin-left: 6px !important;
    margin-right: 6px !important;
  }
}
</style>
7 Likes