Review feed example

[mcking65]

The feed example developed for issue #246 is ready for review.

[Shepard]

Hi, I'm trying to apply this example and noticed two problems with it:

• aria-setsize is not used correctly. According to the spec it is supposed to reflect the total number of available elements when not all of them are currently shown in the DOM. The example sets it to the number of articles in the DOM and updates it whenever more articles are added. Since for a feed the total number is often unknown or undefined or hard to calculate, the spec seems to suggest that "-1" would be the appropriate value here.
• The first note in https://www.w3.org/TR/wai-aria-practices-1.1/#feed mentions that keyboard controls should be documented which is especially important because of the interaction of tabbing and infinite loading: since tabbing scrolls down the page it triggers loading more content meaning you can't tab out of the feed. At the moment the example page does not document the keyboard controls and is therefore in violation of SC 2.1.2 No Keyboard Trap.

I would like to see a good example of how to document keyboard controls in an unobtrusive way so that people who rely on them can find them but it's not too "in your face" for others. This is something I've struggled with in other places. It's probably not the WG's task to come up with good accessible design though, but just to explain the technical bits. :-)

[zcorpan]

https://w3c.github.io/aria-practices/#wai-aria-roles-states-and-properties-9 says

If the feed has a visible title, the feed element has aria-labelledby referring to the element containing the title. Otherwise, the feed element has a label specified with aria-label.

However, the example does not use aria-labelledby or aria-label on the feed element.

[ZoeBijl]

With thanks to @ianthedev for the original report, here’s a aummary of a related issue:

What should happen when Control + Home|End is pressed without a focusable before|after the feed widget? Right now it moves focus to the first article in the feed. If this is the right behaviour this should be documented.

@mcking65 what are your thoughts on this?

---

Proposed changes:

• [ ] Add a focusable before the feed
• [ ] Add documentation about what should happen when there’s no focusable before or after the feed
• [ ] Add aria-labelledby to the feed
• [ ] Set aria-setsize to -1
• [ ] Add keyboard instructions to the example page

[zcorpan]

(moved this comment to a new issue: https://github.com/w3c/aria-practices/issues/1282 )

[robfentress]

I would like to see a good example of how to document keyboard controls in an unobtrusive way so that people who rely on them can find them but it's not too "in your face" for others. This is something I've struggled with in other places. It's probably not the WG's task to come up with good accessible design though, but just to explain the technical bits. :-)

I too have found the current solutions for providing such help text to be lacking. What would be the appropriate channel for getting this kind of thing addressed? Is this a use case that could potentially be addressed by tying into semantics exposed through the Personalization Help and Support module, specifically, helptype, explain, or moreinfo? Theoretically, screen readers could provide affordances for users to have these cues presented to them, right? For instance, users could configure their AT to present the help text by default, based on how they had their software configured, or in response to a key command. Is that part of what was intended to be addressed by the work on Personalization Semantics by the Accessible Platform Architectures Working Group? If so, are they coordinating with screen reader companies to actually implement this kind of functionality?

[maia-miller]

Hi there, in the feed example, there is a dropdown to "Select article loading delay". However, because it comes after the feed, it isn't intuitively keyboard accessible (it can be accessed via Control + End, but I only figured that out by reading a comment in this thread). My suggestion would be to have a skip link before the feed; to code the dropdown to come before the feed; or to provide instructions on how to reach it via keyboard.

Thanks for your efforts!

[stafyniaksacha]

Hi there, this is my feedback: The aria-setsize should be set on the feed element because the information is related to the feed, not to the article (as of the aria-busy) giving us a single source of thrust. In addition, it prevents to update all article DOM nodes when adding new items to the feed.

[DavidMacDonald]

I think each button on the feed should have a unique name. Currently they all have the same name. I suggest each button refer to the title of the tile with either a aria-labelledby. With an id on the button also so it says the title of the tile followed by the title of the button.

[kryp71c]

The semantics of the example could also be improved. The articles are marked up using <div role="article">. According to the W3C article on roles :

Although the role attribute may be used to add semantics to an element, authors should use elements with inherent semantics, such as p, rather than layering semantics on semantically neutral elements, such as div role="paragraph".

Let's eat our own dog-food and change this markup to use an <article> element.

Like @stafyniaksacha, I wish we were allowed to use aria-setsize just once on the parent element; alas the current standards for aria-setsize don't allow that.

I am writing this on a Mac and it seems voiceover still does not support aria-setsize and aria-posinset for role=feed, or at least it is not announcing the position or size in the example. Nor does it announce any status change when aria-busy is set or unset. It would be great to offer some advice for transitional voiceover implementation. As it stands there still appears to be a need for a polite aria-live region to make these announcements on voiceover.

[emamoah]

Hi... Has anyone tested this example on a mobile device, though? It's impossible to utilise the control after the feed, because new articles just keep appearing when you scroll down, rendering it unreachable.

[jbirdgrant2]

Just echoing what another said. Using the "aria-posinset" and "aria-setsize" attributes on an element with the "role" attribute of "article" produces invalid HTML.

[mcking65]

@jbirdgrant2 wrote:

Just echoing what another said. Using the "aria-posinset" and "aria-setsize" attributes on an element with the "role" attribute of "article" produces invalid HTML.

The HTML is valid. See the spec for role article.

[jbirdgrant2]

@jbirdgrant2 wrote:

Just echoing what another said. Using the "aria-posinset" and "aria-setsize" attributes on an element with the "role" attribute of "article" produces invalid HTML.

The HTML is valid. See the spec for role article.

Thanks. The W3C HTML Validator reports those attributes as errors. Perhaps the validator needs to be updated.

[geoffrey-eisenbarth]

I'm also interested in recommendations for documenting the keyboard controls of a feed to the user.

Also, the mdn web docs mention having controls to navigate in and out of nested feeds (e.g., comments inside of a social media post). It would be nice if the official example also contained a nested feed and some info for the recommended keyboard shortcuts to use for navigating between them.

[spudthebud]

Some observations...

Procedure

With JAWS 2024 with verbosity levels high and Announce Live Regions on:

1. Press JAWS + control + b; it shows a list of 10 buttons .

2. Go to the 3rd button.
3. Press JAWS + control + b again; it shows a list of 10 buttons
4. Go to the 6th button. The feed loads more at that point, although there's no aural indication of more loads.
5. Press JAWS + control + b, again, now there's 20 more buttons loaded.

Issue:

• Visual exploring via scrolling causes feed to load making the content easy to find.

• It also gives sighted users a visual indication of content being loaded, i.e., you see it

• In contrast, non-visual exploring via a list of elements does not give an indication that a feed is present and so user may not do the event that causes feed content to load

• There's also no aural indicator when feed content is loaded.

[mcking65]

@spudthebud

First, even though the feed role is part of the ARIA specification, unfortunately that does not mean that it has assistive technology support. It is this kind of problem that thearia-at community group and project is striving to prevent. For new ARIA features going forward, it is the goal of the ARIA-AT community group to help define expected assistive technology expectations, ensure the expectations are implementable by assistive technologies, and validate that the ARIA feature design provides users with effective solutions to the problems they are targeting.

The feed pattern is not yet on the ARIA-AT schedule. We are not moving as fast as originally planned. I believe the obstacles that were blocking greater momentum are nearly behind us and that we will have a more robust schedule by June 30. It seems that interest in the feed pattern is growing and that there could be good reasons for working to include it in the 2024 schedule.

With respect to specific expectations, I anticipate something like the following:

• When navigating with a reading cursor in a feed and focusable elements are encountered, focus will follow the reading cursor so the feed can scroll correctly. The screen reader will not send scroll events; that will be the responsibility of the feed just like in a listbox or tree. The primary difference between feed and composite widgets like tree is that this focus movement will occur even when using a virtual cursor or browse mode.
• When navigating by article or heading in a feed, the screen reader will inform users of their position in the feed. Because focus is moving, the feed can scroll correctly.
• As articles are added or removed, the users will be aware as a result of announcements of position, e.g., article 7 of 10, article 8 of 30.

[spudthebud]

@mcking65 , any idea of what is the expected behavior when a screen reader user navigates by bringing up the dialog box of elements, whether links, buttons, or headings? Currently, with this mode of navigation, it's not evident that those elements are part of a feed. The user may think there are only 10 headings when infact going to the 6th heading would cause 10 more to be loaded.

[geoffrey-eisenbarth]

Having reviewed the JavaScript code in this example, I think it's a bit disingenuous. Pressing "Ctrl+End" should "take you to the next focusable element after the feed," but the example satisfies this requirement by hard coding what the "next focusable element after the feed" is (e.g., the anchorItem that is passed to the construction of aria.Feed()).

I was looking at the code because it seems to be not exactly straightforward to just grab the next and previous "focusable" items outside of the feed itself. In a similar situation, pressing "Ctrl+Home" actually selects the first focusable element in the feed, not the previous focusable element before the feed.

I'm interested to learn how to find these elements in a general sense without explicitly defining them.