Keyboard focus order
A design system ships a checkout form, and a test harness reproduces sequential focus navigation over it so the team can assert the keyboard path without a browser. You receive the element ids in document order, the tabindex value each element declares, and whether each element is disabled. The three lists always have the same length. A disabled element is never reached, and neither is an element whose tabindex is negative. Elements declaring a positive tabindex are reached first, ordered by that value from low to high, and two elements declaring the same value keep their document order. Every element declaring tabindex 0 is reached after all of those, in document order. Return the ids in the order the Tab key reaches them.
keyboard_tab_order(ids: list[str], tab_index: list[int], disabled: list[bool]) → list[str][["email","card","submit"],[0,0,0],[false,false,false]]out["email","card","submit"][["skip","logo","search","cart"],[1,0,2,0],[false,false,false,false]]out["skip","search","logo","cart"][["a","b","c"],[0,-1,0],[false,false,true]]out["a"]State your approach and its time/space complexity out loud before you optimize. Handle the edge cases (empty input, duplicates, overflow), and say why you chose this over the brute force. Green tests are the floor, not the grade.
[["email","card","submit"],[0,0,0],[false,false,false]]["email","card","submit"]not run yetsample[["skip","logo","search","cart"],[1,0,2,0],[false,false,false,false]]["skip","search","logo","cart"]not run yetsample[["a","b","c"],[0,-1,0],[false,false,true]]["a"]not run yetsample