Add heading and separator roles to feed's allowed accessibility children

[smhigley]

Closes #2236

Based on the working group discussion of the linked issue, we decided to make a quick PR to add heading & separator to feed, and work on ARIA role content models separately. At some point, the content model approach may replace the heading/separator addition when it's ready.

Test, Documentation and Implementation tracking

Once this PR has been reviewed and has consensus from the working group, tests should be written and issues should be opened on browsers. Add N/A and check when not applicable.

• "author MUST" tests: N/A
• "user agent MUST" tests: N/A
• Browser implementations (link to issue or commit): N/A
  • WebKit:
  • Gecko:
  • Blink:
• Does this need AT implementations? no
• Related APG Issue/PR: N/A
• MDN Issue/PR: N/A

---

Preview | Diff

[shirsha]

In The feed role , "Authors MAY use heading and separator children in a feed . For example, in a feed of news stories there could be headings separating sets of articles into sequential dates. If a feed does have headings or separators as children, they SHOULD NOT be focusable or contain information necessary for understanding or navigating the feed 's articles ."

Confused with last sentence "If a feed does have headings or separators as children, they SHOULD NOT be focusable or contain information necessary for understanding or navigating the feed 's articles ". May be provide examples like timestamp and name etc. Provide some explicit info

Also, will there be any related info is added to the heading and the separator role?

[giacomo-petri]

Should we consider adding the scrollbar role as an allowed child element?

When dealing with a high but "static" number of articles, showing them on scroll for any reason (e.g. for performance reasons), this setup might be one of the rare cases where an author would want to create a custom scrollbar.
By doing so, it would give the impression that all the content is already fully loaded, allowing users to see the entire scroll progress right from the initial page load.

I understand that the scrollbar can be positioned outside the feed element, but I don't see why the author shouldn't be allowed to place it inside, as the scrollbar is an integral part of the feed document.

Regarding the rest of the addition, I like it. The details about focusability and not including important text are crucial for maintaining a smooth experience for keyboard users.

[smhigley]

Should we consider adding the scrollbar role as an allowed child element?

@giacomo-petri this makes sense to me! Though I think scrollbar should generally be an allowed child of any composite widget, not just feed. Probably as a separate PR, or as part of the roles categorization that @scottaohara mentioned on the last ARIA call -- WDYT?

[smhigley]

@shirsha the sentence you quoted contains an example in it -- "For example, in a feed of news stories there could be headings separating sets of articles into sequential dates." Is that example enough to address your comment, or is there additional information you want included?

I didn't add anything to the heading and separator role sections, since this change doesn't affect their usage outside of feed.

[css-meeting-bot]

The ARIA Working Group just discussed review: normative pr checklist.

The full IRC log of that discussion

<ZoeBijl> topic: review: normative pr checklist
<ZoeBijl> we refined the checklist after monorepo
<ZoeBijl> https://github.com//pull/2245
<ZoeBijl> Github: https://github.com//pull/2245