Originally discovered in w3c/wai-website-theme#201 (comment):
Navigation to specific hashes behaves differently depending on how they're constructed.
When hash begins with qr- followed by a new shortname (e.g. qr-audio-only-and-video-only-prerecorded), navigation typically works, but the following bugs are observed:
- A client-side script error occurs:
Uncaught TypeError: can't access property "top", t.offset() is undefined
- If you navigate to this hash, then scroll, then focus the address bar and hit enter, nothing happens, whereas if you do the same without
qr- it properly scrolls back to the expected content
Some or all of this functionality is reliant on JS, in particular the if (uri.hash()) block within applyurl, and the scrollto function.
Worth noting: IDs are currently set up as follows:
- Each heading has an id of
qr-<old ID> (e.g. qr-media-equiv-av-only-alt)
- Each article has an id of
<new ID> (e.g. audio-only-and-video-only-prerecorded)
It is notable that the problem case involves hashes that do not correspond 1:1 to existing IDs in the document, but have previously been seen in the wild. This may indicate that the ideal fix is in fact outside of this repo: stop using hashes that do not properly exist as IDs in the document (at least, presuming we don't want to either change or add even more IDs). But perhaps there's at least something we can do to avoid the error reported above.
Unsure whether related or tangential: Daniel observed that when testing #navigation-mechanisms-skip with VoiceOver, one time it took him to "Guideline 2.4 – Navigable", while another time he landed straightaway in the 2.4.1 Bypass Blocks H4.
Originally discovered in w3c/wai-website-theme#201 (comment):
Navigation to specific hashes behaves differently depending on how they're constructed.
When hash begins with
qr-followed by a new shortname (e.g.qr-audio-only-and-video-only-prerecorded), navigation typically works, but the following bugs are observed:Uncaught TypeError: can't access property "top", t.offset() is undefinedqr-it properly scrolls back to the expected contentSome or all of this functionality is reliant on JS, in particular the
if (uri.hash())block withinapplyurl, and thescrolltofunction.Worth noting: IDs are currently set up as follows:
qr-<old ID>(e.g.qr-media-equiv-av-only-alt)<new ID>(e.g.audio-only-and-video-only-prerecorded)It is notable that the problem case involves hashes that do not correspond 1:1 to existing IDs in the document, but have previously been seen in the wild. This may indicate that the ideal fix is in fact outside of this repo: stop using hashes that do not properly exist as IDs in the document (at least, presuming we don't want to either change or add even more IDs). But perhaps there's at least something we can do to avoid the error reported above.
Unsure whether related or tangential: Daniel observed that when testing
#navigation-mechanisms-skipwith VoiceOver, one time it took him to "Guideline 2.4 – Navigable", while another time he landed straightaway in the 2.4.1 Bypass Blocks H4.