[Feedback] [UI] Poor accessibility of posts with many comments

[MasterInQuestion]

    Current web UI cannot adequately scale to handle large posts (e.g. 1,000,000 comments).
    The single-page (one-page) design provides poor accessibility: failing at hundreds.

    Live examples:
    https://github.com/MasterInQuestion/TEST/issues/4#issuecomment-1314215587
    https://github.com/orgs/community/discussions/23204
    https://github.com/mozilla-mobile/fenix/issues/17373#issuecomment-932700252

    See also: https://github.com/orgs/community/discussions/139005#discussioncomment-10826647

[benjiallen]

@MasterInQuestion thanks for the feedback, can you help understand if this is a general access issue or an issue that disproportionately affects people with disabilities?

[ghostinhershell]

Hey @MasterInQuestion,

I wanted to ping you here again just in case you missed @benjiallen's question above. Any additional clarification and feedback would help us point you in the right direction. Thanks!

[MasterInQuestion]

    Thanks for your attention.
    This is a general access issue: just try seeking to any particular comment in the presented examples: note its awkwardness.

    As whether this would disproportionately affect people with disabilities:
    I'm not quite sure. And I'm not familiar with accessibility support.

[SantjagoCorkez]

My 2 cents into this.

If a page has large amount of comments, the page only shows some amount of the newest ones, prepending the list of comments with a "Load earlier comments..." button.

That button itself only loads a limited amount of comments, so if the actual number of comments is really large, only a portion of older comments gets loaded and the user needs to press the button again. And again. And again... And at some point the user gets banned because of HTTP/429 Rate Limit.

I've tested that without being authenticated. And after I've authenticated I've tried once more and seems authenticated users are not rate-limited.

But still are required to spam the "Load earlier comments..." button over and over again.

So, if restriction on loading the whole load of the comments is more or less understandable if requested by an anonymous user (to prevent denials of service and/or heavy loads on the backend infrastructure), the same behavior while the user is authenticated cannot be understood. If an authenticated user doesn't get rate-limited whatever happens, why such a user cannot just optionally choose to load the whole bulk at once?

I've just got my browser accidentally crash and when I re-opened the browser the page reverted to its initial state so I needed to spam the button again just to get the whole conversation thread.

[MasterInQuestion]

    One-page wouldn't reliably work whatsoever.
    The proper solution is pagination.

[adamency]

@MasterInQuestion Pagination is the worst solution to suggest to Github, especially since they never allow you to choose the number of elements per page. Have you never tried to search for a specific commit, release, package, or tag of a project in github ? You literally take dozens of minutes clicking hundreds of times on that same button, until finding the page which holds the one you were looking for. While with a git repository, it is found in 5 seconds.

No, the proper solution is to be able to search the full content. And having all comments on the same page is actually one of the few good things that Github has done, since we can thus have a global view of the evolution of the issue from the start to now.

[SantjagoCorkez]

I'd vote for an option to load the whole set of comments at once being available to at least authenticated users. Another separate button near "Load earlier comments..." or a checkbox (unchecked by default) which switches that "Load earlier comments..." button's behavior. That'd at least improve the usability since would provide one with an option to download everything with a single click on once's choice. Would be of more balance between default lazy load which of course is designed in favor of lowering the backend load and an option to still override in some (I presume) rare cases when that's needed.

[MasterInQuestion]

    [ Quote adamency @ CE 2023-02-24 14:33:46 UTC:
https://github.com/orgs/community/discussions/39463#discussioncomment-5100139
    Pagination is the worst solution to suggest to Github, especially since they never allow you to choose the number of elements per page. ]
<^>    While pagination is a must.
    The latter is a different problem.

    “Have you never tried to search for a specific commit, release, package, or tag of a project in github?
    You literally take dozens of minutes clicking hundreds of times on that same button, until finding the page which holds the one you were looking for.”
<^>    I don't. Request parameters exist to request navigation to the desired page. [ Verified "commits", "releases". ]
    But I admit the "commits" is much user unfriendly, comparing to the revision history page in MediaWiki.
    E.g. https://en.wikipedia.org/?action=history

[ "Search commits"
    See the example links on my profile page:
    https://github.com/MasterInQuestion

    Also:
    https://github.com/search?q=repo:curl/curl+DoH&type=commits&s=committer-date&o=desc
    https://github.com/search?q=repo:MasterInQuestion/attach+committer-date:>=2024-03-17&type=commits&s=committer-date&o=asc ]


    "No, the proper solution is to be able to search the full content."
<^>    This is desirable. But irrelevant.

    "And having all comments on the same page is actually one of the few good things that Github has done, ..."
<^>    The scheme is unsustainable. (resource depleting)
    One example: https://github.com/microsoft/vscode/milestone/8