I can look at an activity feed and immediately see that five updates belong together. A screen-reader user needs the app to communicate that relationship through more than spacing and a vertical line.
That is the useful beginner lesson in GitHub's October 8 timeline update. GitHub now exposes timelines as lists to assistive technology, providing orientation such as item count and position. Loading additional events also reports the number added. The announcement says the visual appearance is unchanged.
You could compare two screenshots and miss the improvement entirely.
When you ask AI to build an activity feed, order history, or project log, ask what the user can understand without visually scanning the page. That question belongs in your feature request before you accept the generated implementation.
Here is my starting rule: the user should be able to find the collection, understand one item, request more, and continue without losing their place.
If you want a guided first-build workflow, my $3 AI App Builder Starter Prompts help you turn an idea into a bounded build. Use this article's orientation check as an extra requirement in that workflow, rather than asking AI for a generic accessibility polish pass.
Start with the relationship between items
Imagine a small app that tracks freelance project updates. Its feed contains a milestone approval, a file upload, and a delivery note. AI could build that as three styled containers. They might look like a list while exposing little useful grouping to assistive technology.
The W3C's content-structure tutorial explains how semantic markup communicates meaning and groups information. It distinguishes unordered lists, ordered lists, and description lists according to the relationship between their contents.
My implementation advice is to start with the simplest native structure that fits the content. If sequence matters to the meaning, consider an ordered list. If you are presenting a collection without a meaningful sequence, an unordered list may fit. Do not choose based only on whether the mockup shows bullets: appearance and structure are separate decisions.
Give the collection a clear heading. Make each event understandable: who did what, to which project item, and when? A colored dot or icon can reinforce that meaning, but it should not carry the only explanation.
For a hypothetical event, “Maya approved the homepage milestone, October 8 at 10:15 AM” is more useful than “Approved” beside an unlabeled avatar. Use synthetic people and project data while testing.
You do not need to invent a complex custom widget for a short history. Native elements reduce the amount of behavior you must implement yourself. They still need to be checked in the actual app.
Treat loading more as a change in orientation
A Load more button introduces a second responsibility. The request can succeed at the network layer while the user remains unsure what happened.
For this project-history example, I would write the behavior before requesting code:
- While loading, communicate that the request is in progress and prevent duplicate requests.
- On success, communicate the number of events added.
- On failure, explain that the existing history remains available and provide a retry action.
- When there are no more events, make that state understandable.
Those are product expectations for this example, not a claim that GitHub implements every one of them.
Then decide what happens to focus. Should it remain on the Load more control so the user can continue at their own pace? Should it move to a newly loaded event after an explicit request? The right choice depends on your interaction and the user's task. GitHub's announcement describes moving focus to the newest event; I would not copy that into every feed automatically.
Automatic refresh is a different case from a deliberate button press. An incoming background event should not casually steal focus from a user composing a reply or examining an older update.
Ask AI to state its proposed focus behavior and why. If it cannot explain the choice, the implementation is not ready for you to accept.
Give AI a concrete request
For the hypothetical project log, I would use a request like this:
“Implement the project activity history as a semantically grouped collection with a clear heading. Each event must expose actor, action, target, and time in a meaningful reading order. Specify the focus behavior for an explicit Load more request before coding. Communicate loading, added-event count, failure, and exhaustion without relying on color. Background refresh must preserve the user's current focus. Use synthetic events and explain how I can verify the behavior with keyboard navigation and a screen reader.”
This request names the job and the changing states. It also makes AI explain the parts that a screenshot cannot prove.
Do not accept “added ARIA” as the outcome. Extra attributes can be wrong, redundant, or disconnected from the current state. Ask what a user actually encounters.
Verify a small journey
I would check a three-event history first, then a longer one with loading enabled. Use the platform's screen reader and learn its navigation commands before interpreting the results.
Find the history by its heading. Confirm that the collection and its events are understandable. Read an event without looking at the page. Request more and determine what changed, where focus went, and how you continue. Repeat with a failed request and with no remaining events.
Also use the keyboard without a screen reader. Check that controls are reachable, focus is visible, and the loading state does not strand you. These checks complement each other; one does not substitute for the other.
Record the browser, screen reader, and platform you tried. Say what worked and what remains untested. Automated checks can help detect mistakes, but a clean report does not establish that the journey makes sense.
For a beginner, there is a real tradeoff here: dynamic feeds, virtualization, and custom interactions add behavior that takes time to verify. A short, paginated history can be a better first version than an infinite feed if it lets you deliver understandable navigation reliably. That is a scope decision, not a reason to leave users without access.
Your next step
Pick one collection in your app: tasks, messages, history, or search results. Write down its grouping, each item's meaning, loading feedback, and focus behavior. Ask AI to inspect the existing implementation against those four responsibilities before changing it.
My $3 Starter Prompts are the immediate guided action, with a $20 buyer benefit toward Bootcamp Bundle (Review Radar) when checkout opens. The $9 standalone AI App Builder From Zero e-book gives you an organized path from idea to publication and a $30 benefit; it excludes the separate 40-prompt workbook. The $10 Gumroad learning bundle includes both resources and a $70 benefit.
Bootcamp Bundle (Review Radar) is coming soon, planned at $399 for one app project or $999 for three. Checkout remains closed. Visit the preview to request waitlist updates manually by email; this is launch interest, not automatic registration. It does not promise revenue or a guaranteed finished app.
One verified buyer benefit may be used once when checkout opens. Benefits do not stack, have no cash value, and exclude refunded or disputed purchases. Previously issued benefits keep their original terms. Verified Kindle and Apple combined editions qualify for the $70 benefit; check each store for its price.
A feed is useful when you can follow what happened and continue from where you are. Make that true for someone who cannot see its layout, too.
You can also find me here:
Medium: https://medium.com/@marcusykim
DEV.to: https://dev.to/marcusykim
Website: https://marcusykim.com/
X: https://x.com/marcusykim
LinkedIn: https://www.linkedin.com/in/marcusykim/
Upwork: https://www.upwork.com/freelancers/marcusykim
Top comments (0)