Accessibility Statement

SoftHarbor should work for everyone who wants to find software — including people who use only a keyboard, a screen reader, magnification, voice control or a high-contrast theme. This page says what we aim for, what the site already does, what we know is not right yet, and how to tell us about anything that gets in your way.

What we aim for

Our target is the Web Content Accessibility Guidelines (WCAG) 2.2 at level AA. It is a goal that guides the work, not a claim that every page meets it: no independent audit has been done.

What the site does

• Everything works with a keyboard alone. The first stop on every page is a “Skip to content” link, and the item you are on is always outlined.
• Pages are built from real headings, lists and landmarks, and say which language they are in, so screen readers pronounce English and Vietnamese correctly.
• Text and controls keep their contrast in both the light and the dark theme, checked by an automated test: 7:1 for body text, 4.5:1 for other text, 3:1 for control edges.
• Nothing relies on colour alone: a security status has its own icon shape, and the section you are in is underlined.
• The display settings (the sliders button at the top right) offer a light or dark theme, reduced motion, a thinner or hidden scrollbar, and a switch that turns off the “/” search shortcut. The site also follows your system’s reduced-motion setting and its high-contrast colours.
• Text can be zoomed to 200 %, and the layout reflows down to a narrow phone screen without sideways scrolling.
• When you search or filter, the number of results is announced to screen readers.
• There are no pictures of text. App logos are decoration; the app’s name is text.

How we check it

• On every change: automated accessibility checks (axe, using its WCAG 2.0 to 2.2 A and AA rules) on the main pages in both themes, on a desktop and a phone-sized screen, plus tests for keyboard use, reflow, high-contrast colours and contrast.
• By hand, 9 November 2026: keyboard only, and the Narrator screen reader, on Windows 11 with Chrome, Brave and Firefox.
• Not tested yet: NVDA, JAWS, VoiceOver (macOS and iOS), TalkBack and Safari. Reports from these are especially welcome.

Known limitations

• After you accept the legal notice, a short bot check from Cloudflare (Turnstile) runs. It is a third-party widget we cannot fully control. If it cannot finish, you are let in anyway — after 10 seconds, or 2 minutes if it asked for a click.
• Every listed app links to its developer’s own website and installer. How accessible those are is outside our control; tell the developer, and tell us if a listing should say so.
• App cards shorten the summary to two lines. The full text is on each app’s page.
• The Vietnamese legal pages are translations; the English text is the one that counts.

Report a barrier

Email accessibility@poli0981.dev, or open an accessibility issue on GitHub (that needs a GitHub account; email does not). If you can, say which page you were on, what you were trying to do, what happened, and which device, browser and assistive technology you use. Screenshots or recordings are welcome but never required, and you never need to tell us about a disability. Write in English or Vietnamese.

What happens next

SoftHarbor is run by one person, so these are the promises that can be kept. We reply within 7 days and rate how much the barrier gets in your way:

• Critical — stops you finding, reading or opening an app’s links: fixed within 30 days;
• Serious — hard to get past, though there is a way around: within 60 days;
• Moderate or minor — an annoyance or inconsistency: within 90 days.

If a date slips, we say why, offer a workaround, and give a new date. We may ask you to confirm the fix before the report is closed.

For contributors

How we keep changes accessible — the checks a pull request must pass and what to test by hand — is in ACCESSIBILITY.md in the source repository.