Feed里加载文章与阅读文章，为什么需要双方衔接

界面不断向下增加内容，就已经完整表达Feed了吗？W3C的ARIA Authoring Practices Guide将它描述为随着滚动自动加载内容的文章列表，同时强调Feed是structure，而不是widget。这个区别使阅读文章成为中心，不只是页面上出现了多少张卡片。

文章是Feed中的内容单位。APG说，具备阅读模式的辅助技术，例如屏幕阅读器，在处理这类内容时默认处于阅读模式。相比把整个区域当成一个需要逐项操作的控件，结构的描述更关注文章内部的阅读，以及在文章之间移动。这里采用模式文档的定义，没有实际运行读屏软件。

动态加载却需要进一步协调。页面可能根据滚动不断请求新内容，但这会给辅助技术带来可用性和互操作困难。文档因此引入网页与辅助技术之间的约定，让用户在阅读模式中既能阅读、前后跳到不同文章，也能触发后续内容加载。外观像无限滚动，没有独自证明这种联系已经存在。

网页一侧的职责，与哪一篇文章包含DOM焦点相连：据此适当滚动可见内容，并加载或移除文章。辅助技术一侧则要标识阅读光标位于哪篇文章，通过让文章本身或其后代具有DOM焦点来建立联系，还负责提供文章前后及Feed边界的阅读移动能力。两侧关心同一篇当前文章，才能把阅读位置与内容变化接在一起。

这不是说阅读光标、DOM焦点与可见滚动是同一个名称。它们分别出现在不同职责中，约定使这些状态能够协同。仅从页面代码不断增加内容，不能补记辅助技术已经准确追踪阅读位置；反过来，辅助技术知道当前文章，也仍需要网页按这一位置处理内容。

文章本身还应提供可区分的标签，文档强烈建议另有指向主要内容的描述。标题帮助辨认是哪一篇，主内容的说明帮助略读时判断是否值得继续关注。这些信息有利于从一篇跳到另一篇时理解对象，不是将整篇文章都压缩成一个扁平选项名称。

位置与数量又提供另一组背景。APG为文章保留所在序位，并区分已经加载的文章数量与Feed总数量，说明所取范围取决于哪一种对用户更有帮助。总数未确定时，文档也保留专门表示。已经看到五篇，与整份内容只有五篇，因此不是可以随意替换的描述。

本文只解释正式模式中的阅读结构、双方职责与文章信息，没有转写键盘教程或ARIA配置，也未执行示例。页面首发未知。这些定义不同于Listbox内部名称语义的旧问题：Feed需要让动态内容变化仍围绕可识别的文章阅读，而不是仅凭一张卡片或一个角色名称证明真实界面已经通过无障碍验收。