I hope the screen reader software doesn't read 'link' when it reads the title

[mafanwei]

Feature request

I hope to add a feature that the md file title does not read out the link.

What problem does this feature solve?

Friendly for some people who use screen reader software

What does the proposed API look like?

just like

 window.$docsify = {
      readLink: false,
}

How should this be implemented in your opinion?

I don't think this should be hard to implement, e.g. generating html for md files without a tag.

Are you willing to work on this yourself?

I'm afraid I can't.

[anikethsaha]

Can you give some more info about the request. Like Before/after cases.

[mafanwei]

Thank you for your response.

Here's a simple example:

# Here's a headline

Here's some content

When we use screen reader software, it reads confusing headlines.

[jhildenbiddle]

I believe @mafanwei is referring to the fact that docsify wraps heading text in an <a> tag and as a result screen readers incorrectly describe headings as links:

<h2 id="quick-start">
  <a href="#/quickstart?id=quick-start" data-id="quick-start" class="anchor">
    <span>Quick start</span>
  </a>
</h2>

The issue is that there is no way for screen reader users to distinguish between regular links used for navigation and these special-purpose anchor links (which when clicked update the URL and scroll the page). There are better ways to implement this behavior. Using a <button> element instead of an <a> element is just one example:

<h2 id="quick-start">
  <button data-id="quick-start" class="anchor" aria-label="Quick start. Click to update URL with anchor link.">
    <span>Quick start</span>
  </button>
</h2>

The <button> allows the heading to receive focus via keyboard navigation, and the aria-label is used by screen readers to describe both the content ("Quick start") and the functionality of the button ("Click to update URL with anchor link."). We can use CSS to remove the button styling and allow it to render as standard text:

h2[id] button {
  -webkit-appearance: none;
  appearance: none;
  margin: 0;
  padding: 0;
  border: none;
  background: none;
  font: inherit;
}

The existing JavaScript that updates the URL and scrolls the page would just need to be updated to handle <button> elements instead of <a> elements.

Unfortunately, this is a breaking change that would effect third-party themes and possibly plugins. As a result, a change like the one above would need to be targeted for v5. There may be a way to leverage the ARIA role attribute to change how screen readers describe the current links with the existing v4 implementation, but that require some research and feedback.

[mafanwei]

Thanks for the reply