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

Tab focus lost upon reaching a section link #66

Open
dotherightthing opened this issue Jun 17, 2021 · 1 comment
Open

Tab focus lost upon reaching a section link #66

dotherightthing opened this issue Jun 17, 2021 · 1 comment

Comments

@dotherightthing
Copy link

dotherightthing commented Jun 17, 2021

This page documents the use of GFM:

https://docs.github.com/en/github/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax#section-links

You can link directly to a section in a rendered file by hovering over the section heading to expose the link

However, not all users 'hover' with the mouse. Users finding the keyboard more usable might use the TAB key to explore the content and access links.

Try this test:

  1. Load https://github.com/mojombo/github-flavored-markdown/blob/gh-pages/index.md
  2. Press 'TAB' once to highlight 'Skip to content'
  3. Press 'ENTER' to skip past the navigation to the content
  4. Keep pressing tab until the rubbish bin icon is highlighted ("Fork this project and delete the file")
  5. Press 'TAB' - where has the focus gone?
  6. Press 'TAB' - the focus is on 'Markdown Syntax Guide'

At step 5, the focus is actually on the heading anchor link icon - but the icon is hidden and only appears on hover.

The heading anchor icons use the aria-hidden attribute. This removes elements from the accessibility tree. Screen readers like VoiceOver on macOS ignore this content when generating proprietary content like "links" lists.

This means that screen reader users will not discover these anchors via their screen reader. This is probably what you intended.

However, aria-hidden affects semantics, not mechanics. Specifically, it does not remove elements from the tab order. These elements may still be tabbed to. In your case this results in the focus being 'lost', because at this point, no visible element displays the focus 'outline'.

A keyboard or partially sighted screen reader user may choose to tab between elements, as part of exploring the content.

You can verify the anchor links' attributes in Chrome's Accessibility tab - heading anchors will show as both hidden and Focusable.

To mitigate this, one option is to add tabindex="-1" to the link. This will remove it from the (keyboard) tab order, however a user with sufficient dexterity will still be able to manually activate it via click/touch.

Another option is to remove the aria-hidden attribute so that the element is reintroduced into the accessibility tree. Make the icon accessible on :focus as well as on :hover. Now you will need to make it uniquely identifiable to avoid duplicate links. You could do this by adding an accessible name to the anchor via nested text or the aria-label attribute, or by refactoring the link to incorporate the adjacent heading text.

I don't use a screen reader on a daily basis, but I do test in them. Given the popularity of GFM, ideally all users would be able to navigate it.

@dotherightthing
Copy link
Author

Amber Wilson has put together a deep dive on appropriate solutions: https://amberwilson.co.uk/blog/are-your-anchor-links-accessible/

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

No branches or pull requests

1 participant