Skip to main content


In-Process is out - featuring news on NVDA 2024.4.2, our new add-on survey, a very successful SPEVI 2025 conference, and a User's guide: What to do if your add-on breaks?

Read the full issue now at:
nvaccess.org/post/in-process-2…

and remember, you can now subscribe to receive In-Process via email at: eepurl.com/iuVyjo

#NVDA #NVDAsr #Blog #News #Newsletter #WhatsOn #ScreenReader #Accessibility

Tamas G reshared this.

in reply to NV Access

FYI, the same-page links in the table of contents nav thing for the post don't work for me in Safari on iOS. VoiceOver just indicates that I've returned to the top of the page (to the NVAccess logo link) when I activate them.
in reply to James Scholes

@jscholes Thanks James, is that usual (if you look at previous issues)? I'm using the same setup as previously and they seem to work for me, though I haven't tested in iOS myself yet, I'll check that out.
in reply to NV Access

I tried the links in the December 19th post and got the same behaviour.
in reply to NV Access

I never tried it before today so unfortunately I have no idea.
in reply to James Scholes

@jscholes Do the links other than the first one (ie add-on survey, SPEVI conference etc) - Looking at w3schools.com/html/html_id.asp what I've done should work, ie:
<a href="#C4">Jump to Chapter 4</a> which links to
<h2 id="C4">Chapter 4</h2>

BUT I noticed in there "The id name ... cannot start with a number". The first TOC entry for the 2024.4.2 update has a number for the ID. I've never noticed an issue before, apparently it SHOULD work fine with HTML, but CSS may not: benfrain.com/when-and-where-yo…

in reply to NV Access

@jscholes I'm not sure if Windows / Chrome / Firefox / NVDA are happy to work with my numerical ID, and for some reason IOS / Safari / VoiceOver is not?

I just updated it to ensure ALL the ID's start with letters now. I'd be interested to know if it works now? If not, maybe there is an iOS / Safari / VoiceOver bug?

in reply to NV Access

That hasn't made a difference. But based on your mark-up example, you're missing a tabindex="-1" on the target headings to make them programmatically focusable (headings can't receive focus by default). It's possible that Windows browsers/screen readers aren't picky about that anymore (relying on scroll position only), while Safari still requires it.
This entry was edited (2 hours ago)
in reply to James Scholes

@jscholes This seems to be a Voiceover bug as far as I can tell - the ID should be all that is needed to tell the browser where to go, and that WC3Schools article (& other tutorials I can find) only requires the ID. As far as I can tell tabindex is only required where you want to override the default order of things when physically tabbing around the site (with the tab key)
in reply to NV Access

A `tabindex` value of `"-1"` either:
1. removes an element from the tab order; or
2. makes an element programmatically focusable when it isn't already.

The second category is what applies here, because a heading isn't focusable by default. If you want focus to move to it (in this case by clicking a link) as opposed to the browser only scrolling the page, it should be made focusable via `tabindex="-1"`.

webaim.org/techniques/keyboard…

This entry was edited (2 hours ago)
in reply to James Scholes

Here's an example page which does work correctly with VoiceOver, where the "Tuesday", "Wednesday" and "Thursday" links cause the corresponding headings to be correctly focused because the `<h2>` elements have `tabindex="-1"`.

m4c.space/convening24/program/

in reply to James Scholes

I'll also note that the links on the In-Process page don't actually work correctly in Chrome on Windows either, even though NVDA gives the impression that they do. If you activate e.g. "Add-on survey" and then press NVDA+Tab, you hear:

"NV Access | In-Process 20th January 2025 document focused read only"

... instead of:

"Add-on survey heading focused"

In other words, the page scrolls and NVDA announces the heading, but keyboard focus doesn't actually move there. `tabindex="-1"` will also fix this.

in reply to James Scholes

@marco @jscholes Actually, a target is not required to be focusable in order for a same page link to target it. Target scroll and focus are two different things. If that isn't working on iOS (and there isn't some other bug on the page), Safari or VoiceOver is doing it wrong. This has been allowed and supported by browsers and AT for years.
in reply to Jamie Teh

We still run into instances where skip links targeting headings fail to provide an equitable experience without the target being focusable. It's possible that in such cases, there is something else wrong on the page. At the same time, adding the tabindex fixes the problem, allows SR users to determine the new focus point instead of it being on the body, and provides a visible indication of focus for people who benefit from that (particularly if coupled with :focus-visible).

I think it's good to know if a given technique should no longer technically be required especially if it leads to knowledge of an Apple bug (that they won't fix), but I maintain that there's an easy way to improve this situation with no negative side effects, and so whether it should need the workaround or not is practically moot for users.

On the other hand, we've now spent more time talking about the problem than it would've taken me to read the whole page so... shrug :)

@marco @NVAccess

This entry was edited (2 hours ago)
in reply to James Scholes

@jscholes @jcsteh @marco Also, you need to think about those links for more than just screen reader users.Programmatically moving focus to the main content allows sighted keyboard-only users to bypass repeated content as well, something simply scrolling the screen doesn't do for them.
in reply to Justin Yarbrough

@jyarbrough @jscholes @jcsteh @marco I'm still looking into this - if it helps make it better to access in future, then it's worth it. As well as Wc3 schools, most other guides on creating same page links don't mention tabindex either (specifically adding it to a search I can find some A11y pages talking about it) - it seems like needing an extra tag to provide functionality the same page link should just DO. In what situation would anyone want a same page link to scroll but not move focus?
in reply to NV Access

@jscholes @jcsteh @marco The guidance we provide where I work is to include a tabindex and it's something I was asked about in a technical interview with one of the big accessibility consulting companies here in the US.
in reply to NV Access

@jyarbrough @jcsteh @marco Moving focus can be a sticky topic because it causes an outline/ring to appear around the thing that receives it (at least on accessible sites). Many web designers for some reason have an aversion to this happening when a focus change is triggered with a mouse, and this may explain why browser developers have been hesitant to do more than just scrolling for skip links.

Then again, this is a complete guess and could be wildly off the mark.

in reply to James Scholes

@jscholes Re what NVDA+tab reports - That seems to be exactly the same even if you arrow down to the same place, so while possibly a sepearte bug, I don't think it's relevant here.
in reply to NV Access

NVDA-Tab reports the system focus. If you arrow down the page in browse mode, you're not moving the system focus so the behaviour you're describing is expected and not a bug. I was pointing out that NVDA-Tab is relevant to the discussion because if you allow the heading to receive focus as I'm suggesting, the system focus will move when one of those links is activated, and hence NVDA-Tab will report the heading accordingly.