Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add tabindex Closes #85 #86

Merged
merged 1 commit into from
Mar 19, 2021
Merged

Conversation

thierryk
Copy link
Contributor

@thierryk thierryk commented Mar 10, 2021

tabindex="-1" is to make the user agent focus on the anchor and more...

`tabindex="-1"` is to make the user agent focus on the anchor (the targets of anchor links can then be styled using `:focus`).
@valeriangalliat
Copy link
Owner

I'm confused as on MDN I can read

A negative value (usually tabindex="-1") means that the element is not reachable via sequential keyboard navigation, but could be focused with JavaScript or visually by clicking with the mouse. It's mostly useful to create accessible widgets with JavaScript.

And I can confirm that doing tabindex="-1" removes the anchors from keyboard navigation. Is this really desirable? It seems like the opposite of what you want

@thierryk
Copy link
Contributor Author

And I can confirm that doing tabindex="-1" removes the anchors from keyboard navigation. Is this really desirable? It seems like the opposite of what you want

My PR is about adding this to headings (anchor destination), not links (anchor source). Did I assume wrongly that the slug can only be added to headings? :-(

I created this page to show the "native" behavior (no CSS added) of target elements being focusable or not.

Markdown for these would resemble to this:

## [Introduction](#introduction "Link to Anchor")

Clicking on https://thierryk.github.io/anchors/#a and then on https://thierryk.github.io/anchors/#b shows the benefit of making the target focusable. Even more when that element is a heading, a section with aria-labelledby, etc. From a screen-reader's perspective (at least in Voice Over in my testing), when the user follows the link anchor the target will be spoken if it is focusable but not if it is not.

The advantage of tabindex="-1" versus tabindex="0"is that the former will not create a tab stop while the user tabs through the page but the latter will create a tab stop before the last anchor on that page.

As a side note, using tabindex="-1" on the target of "Skip Links" is a very common pattern.

@valeriangalliat
Copy link
Owner

Ohh sorry I got confused and thought this was putting the attribute on the link, it makes much more sense now!

So if my understanding is correct, setting tabindex="-1" allows to have the same tabbing behaviour as if we didn't set the tabindex attribute, and on screen readers, enables reading the heading when we follow the anchor link whereas it would not have read it if we didn't set the attribute?

@thierryk
Copy link
Contributor Author

tabindex="-1" allows to have the same tabbing behaviour as if we didn't set the tabindex attribute

Correct! (for when it comes to sequential navigation)

on screen readers, enables reading the heading when we follow the anchor link whereas it would not have read it if we didn't set the attribute?

Correct! Voice Over will announce the heading and link after clicking on the "Section B" link, but will remain silent after clicking on the "Section A" link.

Note that we can (visually) experience a similar feedback by following these 2 links: without tabindex vs. with tabindex. With the first link, the UA (browser) does not provide a visual cue about what the target is while with the second link, it applies a focus ring on that element.

I wonder why there is no default styling for :target though...

@thierryk
Copy link
Contributor Author

As a side note, if I recall correctly, OldIE would scroll to the anchor but would not start tabbing navigation from that point unless that anchor had received focus. I recall having to add tabindex="-1" to the target on Yahoo! frontpage for that specific reason.

@valeriangalliat
Copy link
Owner

Awesome, that looks good to me, thank you!

I'll publish it later next week as part of a new version I'm working on :)

@valeriangalliat valeriangalliat merged commit dd9000a into valeriangalliat:master Mar 19, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants