Fullpage.js: navigation: Links do not contain text which hurts accessibility

Created on 11 May 2017  路  14Comments  路  Source: alvarotrigo/fullPage.js

The navigation links do not have any text, which breaks accessibility.

Why It Matters

If a link contains no text, the function or purpose of the link will not be presented to the user. This can introduce confusion for keyboard and screen reader users.

How to Fix It

Provide text within the link that describes the functionality and/or target of that link. Perhaps moving the tooltip into the link is a good fix for this.

Link to isolated reproduction with no external CSS / JS

[Ideally in jsfiddle.net or codepen.io, links to personal websites won't be reviewed unless isolated. Reported issues without a reproduction might get closed.]

Steps to reproduce it

  1. Enable navigation links option
  2. Validate with an accessibility tool like WAVE http://wave.webaim.org/
  3. See error regarding empty links

Versions

All browsers, all devices.

Help needed enhancement fixed on dev

Most helpful comment

Fixed in the latest version 3.0.3

All 14 comments

pa11y catches this as an error as well.

Thanks for the info! I'll mark it as a possible enhancement for the future.
Although the question is: What text should they contain having into account that:

  • Tooltips are optional
  • Anchors in the URL are optional

The possible solutions I see are:

  • Adding the tooltip within the link when existent as well as keeping the tooltip where it is at the moment
  • If not: adding the anchor within the link when existent as well as keeping the tooltip where it is at the moment
  • Otherwise adding the section / slide index.

The purpose of keeping the current tooltip in the same position in the DOM as its now is mainly to prevent a breaking update for sites styling current tooltips as well as to keep the existent navigations elements functional without any extra work from my side.

I encountered this issue as well, some people with bad eye sight (Like myself) could not see the small dots. I went ahead and changed the css a little to make them larger and more noticeable because I think if user can see the dots clearly their purpose is obviously navigation.

fp-nav ul li a span, .fp-slidesNav ul li a span {

background: #7eff00;
border: 3px solid #7eff00;

}

fp-nav ul li a.active span,

.fp-slidesNav ul li a.active span,

fp-nav ul li:hover a.active span,

.fp-slidesNav ul li:hover a.active span{
height: 15px;
width: 15px;

margin: -6px 0 0 -6px;
border-radius: 100%;
}

Could we not assign an aria-label attribute to each navigation dot with the assigned text?
In quick testing, this seems to satisfy the accessiblity plugin AXE. Not sure if screen readers would read the nav dots twice though.

Could we not assign an aria-label attribute to each navigation dot with the assigned text?
In quick testing, this seems to satisfy the accessiblity plugin AXE. Not sure if screen readers would read the nav dots twice though.

Any feedback on this?

Any update on this? I'm getting the same empty links error in WAVE accessibility tool

Not really. But I'm open to any pull request or suggestion

Could we not assign an aria-label attribute to each navigation dot with the assigned text?
In quick testing, this seems to satisfy the accessiblity plugin AXE. Not sure if screen readers would read the nav dots twice though.

Any feedback on this?

My reading of the spec is that aria-label or aria-labelledby attributes would be NOT sufficient for this:

https://www.w3.org/TR/WCAG21/#link-purpose-in-context

The purpose of each link can be determined from the link text alone or from the link text together with its programmatically determined link context, except where the purpose of the link would be ambiguous to users in general.

Edited: meant to say NOT sufficient.

My reading of the spec is that aria-label or aria-labelledby attributes would be sufficient for this:

@charlesprescottcollins so, you suggest adding the attribute aria-label to the a element like this?:

When using tooltips:

<li>
     <a href="#firstPage" class="active" aria-label="First page">
           <span></span>
     </a>
     <div class="fp-tooltip fp-right">First page</div>
</li>

When using anchors

<li>
     <a href="#firstPage" class="active" aria-label="introduction">
           <span></span>
     </a>
</li>

When not using anchors:

<li>
     <a href="#firstPage" class="active" aria-label="page-1">
           <span></span>
     </a>
</li>

@alvarotrigo I meant to say that aria-label will NOT work for this. I edited my above statement.

Ultimately I think the steps you outlined originally will work except with a change:

navigationText = Anchor text || tooltip text || slide index;

Where slide index should be "Slide [slide index]" e.g. "Slide 3"

I would suggest hiding the text via something like this ( in cases that it makes sense):

from Bootstrap source, https://github.com/twbs/bootstrap/blob/e57a2f244ba8446fffe71847e6a58b18f7b2d541/scss/mixins/_screen-reader.scss

@mixin sr-only {
  position: absolute;
  width: 1px;
  height: 1px;
  padding: 0;
  overflow: hidden;
  clip: rect(0, 0, 0, 0);
  white-space: nowrap;
  border: 0;
}

navigationText = Anchor text || tooltip text || slide index;

Are you there implying priority for the anchor text vs the tooltip text?

Where slide index should be "Slide [slide index]" e.g. "Slide 3"

Then "Section 3" for sections and "Slide 3" for slides. Rather than "page" or "slide"?

I would suggest hiding the text via something like this ( in cases that it makes sense):

Thanks for that! Yeap, I guess some CSS will do it!

Are you there implying priority for the anchor text vs the tooltip text?

Yes, the anchor text should be the most concise description of the link. The tooltip will still be readable.

Then "Section 3" for sections and "Slide 3" for slides. Rather than "page" or "slide"?

That would be fine also.

I guess some CSS will do it!

Glad it helped!

Yes, the anchor text should be the most concise description of the link. The tooltip will still be readable.

I opted to use the Tooltip as a priority over the anchor. Reason being anchors can be a bit less readable as they can not have spaces or non URL characters.
For example:

"introduction-to-page", "introductionToPage", "idontlikeit"
vs
"Introduction to page", "I don't like it"

Ok so, just to confirm. This fix would solve the WAVE accessibility tool error that @karlbalagtey mentioned, but will generate warnings on them:

3 X Broken same-page linkMore information

This is due to the anchor links (such as #firstPage) that are not linking to any id target on the page.
But... this has no solution as far as I know. In fact, fullPage.js requieres anchors not to match any id or name attribute in order to function properly.

Please see the changes I made and let me know if you want to add anything else.
Notice I applied them not only for vertical bullets but also for horizontal ones.

And thanks for all your feedback!

Fixed in the latest version 3.0.3

Was this page helpful?
0 / 5 - 0 ratings