[Site] Fix mobile tabindex

[paulcam206]

Related Issue

Fixes VSO 30943285

Description

I apologize in advance. Header and mobile nav is powered by some JS we don't own (and can't change on any reasonable time scale). There are a couple of problems with this script. The first is that it puts explicit positive tabindex attributes on some DOM elements when in what it considers to be a "mobile" view (this is keyed off of the window width, so it is also affected by DPI and zoom levels). Using positive tabindex values is considered bad practice because it's easy to get wrong. Anyways, this is the reason why the tab order is messed up in mobile. The second (relatively minor) problem is that it views the templating checkbox as a search box (it just looks for the first <input /> in the DOM).

The fix reads easy enough, but I'm not proud of it (though it works):

• Add an explicit tabindex="0" to the templating checkbox to give it a reasonable default.
• Introduce makeTabIndicesZero(), which finds everything on the page that has a tabindex property, and then sets that property to 0 as it should be.
• Call makeTabIndicesZero() on window resize (covers active zooming case).
• Call makeTabIndicesZero() on document load, but do it behind a setTimeout call so that it runs after the offending JS. This is the part I'm least happy about, but the offending JS is itself being run something like setTimeout(ruinSomeTabIndices, 4); (yes, 4).

How Verified

• local build, devtools, keyboard

Microsoft Reviewers: Open in CodeFlow

[ghost]

Hi @paulcam206. Thanks for helping make the AdaptiveCards JS renderer + tooling better. As additional verification, once the JS build succeeds, please go to the test site to test out your website/designer changes.

[RebeccaAnne]

Heh. This will do it i guess, but is there a way to like log a bug against whoever does own the bad script so that someday eventually their script will be less broken?

[RebeccaAnne]

[golddove]

If we have less than 5 pending accessibility issues, we should consider waiting for a proper UHF fix instead. Either that, or track a new issue to change it.

[golddove]

Perhaps we should only make the indices zero if they're not set to a negative number? This way, if anything was explicitly removed from tab order, we don't change those.

[paulcam206]

that's a good point -- fix inbound shortly

[paulcam206]

If we have less than 5 pending accessibility issues, we should consider waiting for a proper UHF fix instead. Either that, or track a new issue to change it.

unfortunately, I don't think we can count on a fix coming any time soon. we're basically using a cobbled-together UHF drop, so we're not likely to be in a supported config. that said, we should probably file an issue to modernize our UHF consumption. I'll do that. :)