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 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

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 (3 months 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 (3 months ago)
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 (3 months ago)
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

@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 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.