Disrespectful handling of previous accessibility issues — re-posting with full technical details

[baich110]

🚨 This is NOT a duplicate — this is a condemnation of how you treat contributors

I previously submitted two detailed accessibility issues (#2800 in Chinese, #2801 in English) after conducting a thorough source code audit of the OpenList frontend. Both were summarily closed by @jyxjjj with the label "duplicate" — without a single comment, without pointing to which issue they supposedly duplicate, and without any acknowledgment of the work put in.

Let me be clear: closing a contributor's issue without any explanation is not just poor project management — it's disrespectful. A visually impaired user spent hours analyzing your source code file by file, documenting exact locations and fix recommendations, and the response was silence followed by a door slammed in their face.

If these are genuinely duplicates, the minimum standard of decency is to leave a comment saying "Thank you, this is already tracked in #xxx". Zero comments, zero explanation, zero gratitude — that's not how you treat people who volunteer their time to improve your project.

---

Below is the full content of the previously submitted issues, reposted in full. If this is truly a duplicate, I expect at least the courtesy of a comment pointing to the relevant issue. Otherwise, I expect this to be treated as the serious accessibility report it is.

---

Background

I am a visually impaired user who relies entirely on TalkBack (Android screen reader) to use my phone. OpenList is a powerful file storage mounting tool with extensive storage service support, but its accessibility on Android is severely lacking, making it nearly impossible for visually impaired users to use core features.

OpenList's Android app renders its UI through a WebView loading a Web interface. While this architecture works functionally, it introduces inherent accessibility deficiencies — interactive elements in the Web interface often lack ARIA semantic annotations, preventing TalkBack from correctly identifying and operating them.

Source Code Audit

We conducted a file-by-file audit of both the OpenList backend (OpenListTeam/OpenList) and frontend (OpenListTeam/OpenList-Frontend). The backend is a pure Go API service with no accessibility issues — all problems are concentrated in the frontend Web interface. The frontend is built with SolidJS + Hope UI. All findings below are based on actual source code locations.

Issues Found

1. File List Items Have Zero Accessibility Semantics (Blocker/Critical)

Source: src/pages/home/folder/ListItem.tsx, src/pages/home/folder/GridItem.tsx

The file list is OpenList's core interaction area, but TalkBack users cannot effectively browse or operate files:

• List item container <HStack> has no role="listitem" and no aria-label — TalkBack reads out meaningless text fragments
• File names are rendered with <Text title={props.obj.name}>, but the title attribute is not read aloud by TalkBack
• File name, file size, and modification time are separate <Text> elements — TalkBack reads them one by one, making it impossible to quickly locate target files
• Click/double-click to open folders is bound to on:click and on:dblclick, but the container has no role="link" or role="button" — TalkBack users cannot tell it's interactive
• Grid view GridItem.tsx thumbnail <ImageWithError> has no alt attribute
• Checkbox <ItemCheckbox> has checked and onChange but no aria-label indicating which file is being selected

2. Context Menu Completely Unreachable by TalkBack (Blocker/Critical)

Source: src/pages/home/folder/context-menu.tsx

The operation menu (download, rename, delete, copy, move, share, etc.) triggered by long-pressing a file is completely inaccessible to TalkBack users:

• Uses solid-contextmenu library, menu triggered via onContextMenu (right-click event) — Android TalkBack has no right-click event
• Menu items <Item> have no role="menuitem" and no aria-label
• No focus management when menu appears (first menu item is not auto-focused)
• Submenus <Submenu> also lack ARIA semantics

3. File List Container Lacks Semantic Structure (Barrier/High)

Source: src/pages/home/folder/List.tsx, src/pages/home/folder/Grid.tsx

• List container <VStack class="list"> has no role="list"
• Sort buttons in list title (clicking column names to sort) have no role="button" or aria-label — TalkBack cannot tell they are clickable sort controls
• Select-all checkbox has no aria-label="Select all"

4. Page Landmarks Completely Missing (Barrier/High)

Source: index.html, src/pages/home/Layout.tsx, src/pages/home/header/Header.tsx, src/pages/home/Nav.tsx

The entire Web interface lacks WAI-ARIA landmark markers, preventing TalkBack users from using landmark navigation:

• index.html has <html lang="en"> — should be dynamically set based on locale
• No <main> tag, main content area has no role="main"
• No <nav> tag, breadcrumb navigation (Nav.tsx <Breadcrumb>) has no role="navigation" + aria-label
• No <header> tag, top bar (Header.tsx) has no role="banner"
• Search area has no role="search"

5. Dynamic Content Updates Not Announced (Barrier/Medium)

A full-project search found zero aria-live, zero role="status", zero aria-busy:

• File upload/download progress changes are not announced by TalkBack
• Success/error Toast notifications are invisible to TalkBack
• Loading states (CenterLoading component) have no aria-busy or role="status"

6. Toolbar Buttons Lack Labels (Barrier/High)

Source: src/pages/home/toolbar/Toolbar.tsx and subcomponents (Upload.tsx, Mkdir.tsx, Delete.tsx, Rename.tsx, CopyMove.tsx, Download.tsx, Share.tsx, etc.)

• Toolbar buttons for upload, new folder, batch rename, copy, move, delete, etc.
• Heavy use of Icon components for icon buttons with only visual icons and no aria-label
• TalkBack announces "button" but cannot convey the specific function

7. File Preview Partially Accessible but Incomplete (Barrier/High)

Source: src/pages/home/previews/ directory

Positive: Image preview (image.tsx) has fairly complete aria-label (zoom, rotate, navigate, etc.), paginator (Paginator.tsx) has aria-label="Previous" / "Next".

Issues:

• Video player (video.tsx, video_box.tsx) play/pause/progress bar controls lack accessibility annotations
• Document preview (doc.tsx, pdf.tsx) iframe lacks title attribute
• iframe.tsx has aria-label="Open in new tab" on the link but the iframe itself lacks title

8. Form Element Labels Incomplete (Barrier/Medium)

Source: src/pages/manage/storages/AddOrEdit.tsx, src/components/ModalInput.tsx, etc.

• Some inputs are indirectly labeled via Modal title prop, but lack direct aria-label association
• Storage configuration page has complex forms with many dropdowns and inputs lacking accessibility labels

Existing Accessibility Implementation (Positive Findings)

Approximately 25 aria-label instances found across the project, concentrated in:

• ✅ Image preview controls (zoom, rotate, navigate) — fairly complete
• ✅ Paginator (previous/next) — basic labeling
• ✅ Search box — has aria-label="search"
• ✅ Layout switch — has aria-label="switch layout"
• ✅ Folder tree selector — confirm/cancel buttons labeled

This shows the development team has accessibility awareness, but current coverage is far from sufficient — core interaction areas (file list, context menu, toolbar) are completely blank.

Fix Recommendations

Issue	Source File	Fix	Priority
File list items unreadable	ListItem.tsx, GridItem.tsx	Add role="listitem" + aria-label="filename, size, modified" to container, merge multi-field info into one announceable unit	Critical
Context menu unreachable	context-menu.tsx	Add role="menu" to container, role="menuitem" + aria-label to items, auto-focus first item on open; consider alternative long-press trigger for mobile	Critical
List container missing semantics	List.tsx, Grid.tsx	Add role="list" to container, role="button" + aria-label to sort controls, aria-label to select-all checkbox	High
Page landmarks missing	index.html, Layout.tsx	Add <main>/<nav>/<header> semantic tags or corresponding role, fix lang attribute	High
Toolbar buttons unlabeled	toolbar/*.tsx	Add aria-label to all icon buttons	High
Dynamic content not announced	Global notification components	Use role="status" or aria-live="polite" for success, aria-live="assertive" for errors	Medium
Form elements unlabeled	manage/storages/AddOrEdit.tsx etc.	Add aria-label to all inputs, aria-label + aria-activedescendant to dropdowns	Medium
File preview incomplete	previews/video.tsx etc.	Add role="slider" + aria-label to video controls, title to iframes	High

References

1. W3C WCAG 2.1 Quick Guide

The official W3C Web Content Accessibility Guidelines, the accessibility standard basis for all Web applications. OpenList should follow WCAG 2.1 AA level.

• Official doc: https://www.w3.org/WAI/WCAG21/quickref/
• Four principles: Perceivable, Operable, Understandable, Robust

2. WAI-ARIA Best Practices

W3C's ARIA specification provides semantic annotation standards for dynamic Web applications.

• Official doc: https://www.w3.org/WAI/ARIA/apg/
• Key patterns: Menu, Listbox, Dialog, Tab

3. GitHub Official Open Source Accessibility Best Practices

GitHub's official open source guide recommends every project:

• Create an ACCESSIBILITY.md file declaring accessibility commitment
• Create accessibility Issue templates
• Add accessibility checks to PR checklists
• Prioritize blocking issues (Critical level)

Source: https://opensource.guide/accessibility-best-practices-for-your-project/

Community Collaboration

About Us

We are from the Chinese visually impaired community, with over 20,000 visually impaired developers and over 200,000 visually impaired users, covering mainstream Chinese screen reader user groups (Tantan Screen Reader, TalkBack, etc.).

Testing Collaboration

If the development team is willing to advance accessibility optimization, we can organize systematic testing by visually impaired community users after the first fix release, covering multi-device, multi-screen-reader real-world scenarios, and provide structured feedback reports.

Promotion Willingness

OpenList, as the most feature-rich open-source file storage mounting tool, could gain significant community reputation and user growth in the visually impaired community if it takes the lead in accessibility. We are willing to promote OpenList's visibility within the visually impaired community.

Environment

• Device: Redmi K80 Ultra (dali)
• Android: 16 (API 36)
• Screen reader: Tantan Screen Reader, based on Android AccessibilityService framework
• OpenList deployment: Android App

---

To the OpenList team: I am happy to work with you to make OpenList accessible to everyone. But I expect to be treated with basic respect. A single comment acknowledging the report would have been enough. Instead, you chose silence. Don't let it happen again.

[baich110]

⚠️ 48-HOUR PUBLIC NOTICE: @OpenListTeam, this is unacceptable

@jyxjjj — I'm addressing you directly.

@xhofe — As the primary maintainer (1433 commits) of this 23,000+ star project, I expect you to be aware of how your team treats contributors.

---

The Facts

On July 17, 2026, @jyxjjj closed two of my accessibility issues:

Issue	Language	Actions Taken
#2800	中文	Marked as duplicate → closed — 0 comments
#2801	English	Closed directly — not even marked as duplicate — 0 comments

Both issues contained thorough source code audits with exact file locations, line numbers, and Compose Semantics API fix recommendations. I am a visually impaired developer who spent hours analyzing your codebase to help make OpenList accessible. The response? Silence, then a door slammed in my face.

The Contrast

I submitted a similar accessibility issue to the Operit project (AAswordman/Operit #735) on the same day. Here's what happened:

	OpenList	Operit
Response time	❌ Immediate close	✅ 24 hours — detailed dev plan
Comments	❌ Zero	✅ 10 comments with technical discussion
Action taken	❌ Closed without explanation	✅ P0 test build released in 2 days
Attitude	🚫 Disrespectful	🎯 Genuinely valued contribution

Let me emphasize this: The Operit team, working entirely in their spare time (as stated by the developer), produced a four-phase accessibility roadmap and a working P0 test build within 48 hours. Meanwhile, OpenList — a 23,000+ star project — couldn't even leave a single comment saying "thank you, this is tracked elsewhere."

The Community Behind Me

I am the founder of a visually impaired developer community in China with:

• 20,000+ visually impaired developers
• 200,000+ visually impaired users

This community is actively looking for accessible AI tools. OpenList could have been one of them. Instead, this experience will be shared as a case study of how NOT to treat accessibility contributors.

My Demands

1. Within 48 hours: @jyxjjj or another maintainer must explain which existing issues [Accessibility] Android WebView 界面对 TalkBack 视障用户存在严重无障碍问题，文件浏览与操作完全不可达 #2800 and [Accessibility] Android WebView interface has severe accessibility issues for TalkBack visually impaired users — file browsing and operations completely inaccessible #2801 supposedly duplicated. If they were genuine duplicates, a simple comment pointing to the reference would have sufficed. The fact that none was left suggests either:

   • There are no duplicates and this was a cover-up, OR
   • The maintainer couldn't be bothered to provide basic courtesy

2. Re-open [Accessibility] Android WebView 界面对 TalkBack 视障用户存在严重无障碍问题，文件浏览与操作完全不可达 #2800 and [Accessibility] Android WebView interface has severe accessibility issues for TalkBack visually impaired users — file browsing and operations completely inaccessible #2801, or merge their content into the referenced issues

3. Publicly apologize for the dismissive treatment of an accessibility contribution

4. Implement a basic accessibility contribution policy — at minimum, a DUPLICATE close must include a comment pointing to the original issue. GitHub's own open-source guide explicitly requires this.

The Clock is Ticking

If there is no meaningful response within 48 hours (by July 22, 2026), I will:

• Post this entire exchange to Hacker News and r/opensource
• Share with accessibility advocacy groups worldwide
• Publish a detailed blog post comparing OpenList's treatment of accessibility contributors vs. other open-source projects

**

@jyxjjj — I'm not going away. You closed my issues without a word. I'm reopening this conversation publicly.

@xhofe — Your project has 23,000+ stars and 2,000+ forks. With that visibility comes responsibility. How you handle this will define whether OpenList is known as a project that respects its contributors, or one that silences them.

[jyxjjj]

Did I not link your PR to the corresponding issue? Or I didn't link the duplicate one to it?

[ILoveScratch2]

@baich110

Your two issues were closed as duplicates because we already have existing tracking for accessibility improvements.

Your use of words like “condemnation”, “disrespectful”, and “Don't let it happen again” is unacceptable. Open source maintainers are NOT NOT customer service agents. We do not respond well to threats, commands, or emotional blackmail. We welcome constructive contributions, but we will not be bullied into changing our processes or priorities by aggressive language. If you want to help, act like a collaborator, not a prosecutor.

[ILoveScratch2]

The CLOSURE itself was NOT arbitrary.

The issues you raised cover accessibility gaps that we are already aware of — some have been tracked internally, others have been discussed in earlier threads (though not always publicly labelled). We did not “cover up” anything, it DOES not invalidate the closure.

[ILoveScratch2]

WE WILL NOT apologise for managing duplicate issues. That is standard practice in every active open‑source project. We also do not accept the characterisation of “dismissive treatment”.

We value accessibility work, but we also value the time of our maintainers, who handle dozens of issues each week.

[ILoveScratch2]

@xhofe — As the primary maintainer (1433 commits) of this 23,000+ star project, I expect you to be aware of how your team treats contributors.
@xhofe — Your project has 23,000+ stars and 2,000+ forks. With that visibility comes responsibility. How you handle this will define whether OpenList is known as a project that respects its contributors, or one that silences them.

OpenList is a FORK of the original xhofe project; its current maintenance and operation have no connection to xhofe. Attacking him serves no purpose, and putting pressure through public shaming is even less effective.

[ILoveScratch2]

Even if you choose to raise this on other platforms, it will not change the facts. The issue has already been linked, and the work we have completed is visible to everyone. However, the way you have handled this matter may not be viewed positively by the community and could be considered inconsistent with our community guidelines. We encourage constructive communication and a focus on resolving issues collaboratively.

[PIKACHUIM]

Thank you for your feedback. In fact, we have taken note of your feedback regarding support for visually impaired users, and we have always been very concerned about the accessibility of this project for visually impaired individuals. Therefore, we do plan to address issues including those you mentioned before the next major release (5.0).

However, I need to point out that this project is a public-interest initiative, and our team members and contributors have devoted a significant amount of their time on a voluntary basis. For this reason, we use standardized issue templates to receive issues. If a feedback or issue is not filled out according to the template or if duplicate issues are submitted, closing such issues is reasonable and in line with common practice in open-source projects—we hope you understand and comply.

[baich110]

@jyxjjj @ILoveScratch2 @PIKACHUIM

Let me address everyone's points in one place.

---

To @jyxjjj:

You asked: "Did I not link your PR to the corresponding issue? Or I didn't link the duplicate one to it?"

The answer is: you linked my PR to #2800, yes. But that's not the point. The point is you closed #2800 and #2801 without a single comment. Not "this is a duplicate of #XXX." Not "we're already tracking this." Not even "thank you for your contribution." Nothing. A link in a PR description is not a substitute for basic communication. When someone spends hours analyzing your codebase and writing detailed accessibility reports, the least you can do is leave a comment saying why it was closed. That's not a favor. That's common courtesy.

---

To @ILoveScratch2:

You have multiple comments, so let me go through them.

On the "prosecutor" characterization:

This doesn't hold up. A prosecutor brings charges against someone who has done wrong — and that's exactly what happened here. I didn't invent a problem. I reported one. The difference is, a prosecutor at least has evidence to back up their case. And I do: two closed issues with zero comments, zero explanations, zero courtesy. If presenting facts makes me a prosecutor in your eyes, then maybe the problem isn't how I presented it — it's what the facts say about your team.

On "threats, commands, or emotional blackmail":

Let me be clear: I am not emotional about this. I am not begging you, and I am not playing on anyone's sympathy. I know exactly how open source works — I run a community of 20,000+ developers myself. I don't have the time or the patience for emotional appeals, and I didn't make any. What I did was state facts, set expectations, and outline consequences. That's not emotional blackmail. That's called being direct. If your team can't tell the difference between someone being emotional and someone being straightforward, that's a communication problem on your end, not mine.

In fact, I'd argue that you were more aggressive than I was. I spent hours analyzing your codebase, line by line, producing detailed technical reports with source locations and fix recommendations. What did you do? You closed my work without a word. And when I asked for an explanation, you called me "a prosecutor," accused me of "emotional blackmail," and told me to "act like a collaborator." That's not "managing issues." That's deflecting. Maybe my words hit a nerve. Maybe they exposed something uncomfortable. But calling the person who raised the problem "aggressive" is not a rebuttal — it's an avoidance tactic.

On "the closure was not arbitrary — we already have internal tracking":

Here's the thing: I didn't know that. Nobody told me. When I saw my issues closed, there was no comment, no link, no "hey, we're already tracking this here." Just silence. So from my perspective, my work — hours of source code analysis, line-by-line auditing — was thrown into a black hole. No explanation. No acknowledgment. Nothing. How exactly was I supposed to know it was "already tracked internally" when the only thing I saw was a closed door with no note on it?

I posted one issue in Chinese and one in English because I didn't know what language your project preferred for accessibility topics. I covered my bases. I didn't see any template requirement for accessibility issues — if there is one, it wasn't obvious, and closing someone's work without pointing them to the right template is not "standard practice," it's poor onboarding.

On "we will not apologize for managing duplicate issues":

I'm not asking for an apology for managing duplicates. I'm asking for an apology for how it was done. Closing an issue without a single word of explanation is not "standard practice." It's dismissive. Even GitHub's own interface offers a "close as duplicate" option with a required text field pointing to the original issue. You didn't use it. You just closed it. That's not "managing." That's ignoring.

On "OpenList is a fork, xhofe has no connection":

Noted. Thank you for the clarification. Then I will redirect my expectations to the current maintainers — which includes you, @ILoveScratch2, and @jyxjjj, and @PIKACHUIM. The responsibility rests with you now.

On "raising this on other platforms won't change the facts":

You're right. The facts won't change. But how they are perceived might. I'm not threatening you — I'm being transparent about what I will do if there is no meaningful resolution. That's not "inconsistent with community guidelines." That's called accountability.

---

To @PIKACHUIM:

Thank you for your response. I genuinely appreciate that you acknowledged the accessibility issues and stated that they will be addressed in version 5.0. That is the most constructive thing anyone has said in this entire thread, and I respect that.

However, I need to push back on one point. You said the issues were closed because they "did not follow the template" or were "duplicates." Let me ask you this: did you personally read #2800 and #2801 before they were closed? If you had, you would have seen that they contained detailed source code analysis with exact file paths, line numbers, and Compose Semantics API fix recommendations. That is not a "low-effort report." That is a high-quality contribution by any standard.

And about the template — I didn't see any specific template for accessibility issues. If there was one, it wasn't prominently displayed. Closing someone's work without pointing them to the right process is not "standard practice." It's a failure of onboarding.

You say this is a public-interest project and contributors volunteer their time. I understand that completely — I do the same in my own community. But that works both ways. I also volunteered my time to analyze your codebase and write those issues. The difference is, when I'm done, I expect the bare minimum: a response. Not a closed door.

---

To all three of you:

Let me end with a question that I genuinely want you to think about:

Was closing my two issues without a single word of explanation the best this project could do?

If the answer is yes, then I think we have a fundamental disagreement about what "open source" means.

If the answer is no — and I suspect it is — then let's stop defending the process and start fixing it. Acknowledge that it could have been handled better. That's all I'm asking. Not a policy change. Not a public apology tour. Just an acknowledgment that a contributor deserved better.

I'm not here to fight. I'm here to get a response. And now I have several. So thank you for that — it's better than silence.

But let's not pretend that closing two issues without a single word is "standard practice" in any project that claims to value its contributors. It's not. And you know it.

[jyxjjj]

When I linked it to #2800? Where is the hallucination?

[baich110]

@jyxjjj test

[baich110]

@jyxjjj Let me quote you - twice.

Your first comment:
"Did I not link your PR to the corresponding issue? Or I didn't link the duplicate one to it?"

Your latest comment:
"When I linked it to #2800? Where is the hallucination?"

These two comments are from the same person, on the same day, about the same issue. They directly contradict each other.

Let me help you with the actual facts - I checked the GitHub API.

Issue #2800 event log:

1. marked_as_duplicate - the source field is empty. No link.
2. closed - reason: duplicate. Still no link.
3. The duplicate_of field on the issue? None.

Issue #2801 event log:

1. closed - reason: duplicate. No marked_as_duplicate event. No link. No comment.

So which issue did #2800 duplicate? Give me a number. If you cannot, then you know the duplicate label was just a shortcut to close without explanation.

There is an old Chinese saying:

"人不要脸，天下无敌。树不要皮，必死无疑。"
(A person who has lost all sense of shame is invincible under heaven. A tree without bark is doomed to die.)

I am not asking for a confession. I am asking for a number. What issue did #2800 duplicate? One number. If you can provide it, I will apologize for the entire thread. If you cannot, then we both know what really happened here.

[jyxjjj]

那我觉得你可能不仅仅是瞎，随你怎么说吧，你要乐意发文就发文，自然会有人去看完整的操作日志，你自己的PR都有对应的链接目标，我不相信GH会没有任何邮件发给你