Accessibility Statement

1. Our commitment

mk0.net is committed to making both this website and our iOS applications accessible to people with disabilities. We treat accessibility as a default rather than a feature, and we improve it incrementally with every release.

2. Standards we follow

This website aims to conform to the Web Content Accessibility Guidelines (WCAG) 2.1, Level AA. Our iOS applications aim to support Apple's accessibility frameworks at parity with the platform: VoiceOver, Dynamic Type, Increase Contrast, Reduce Motion, Switch Control, and Voice Control.

3. Features that are in place today

3.1 On this website

• Semantic HTML landmarks (header, nav, main, footer) on every page.
• Skip-to-content link at the top of every page, visible on keyboard focus.
• One <h1> per page and a logical heading hierarchy.
• ARIA labels on every icon-only button (hamburger menu, back-to-top, search, lightbox controls).
• All images have descriptive alt attributes; purely decorative graphics use aria-hidden="true".
• Keyboard navigation throughout: tab order is logical, focus is visible, and interactive controls respond to Enter and Space.
• Keyboard shortcuts: / to focus search, Esc to clear, ? to open the help dialog.
• prefers-reduced-motion media query disables animation for users who request it.
• Color contrast targets WCAG AA at minimum on body text, with most surfaces meeting AAA.
• The cookie consent banner is dismissable by keyboard and announced to screen readers.

3.2 Inside our iOS apps

• Every interactive element has a VoiceOver label, hint, and (where appropriate) value.
• Layouts respect Dynamic Type from the smallest to the largest accessibility sizes.
• No information is conveyed by color alone; icons or text accompany state changes.
• Reduce Motion replaces non-essential transitions with a simple cross-fade.
• Increase Contrast is honored automatically through Apple's system colors.

4. Known limitations

We are not yet perfect. Specifically:

• The app screenshot gallery on detail pages relies on JavaScript. With JavaScript disabled, the gallery is not rendered, though the rest of the page remains fully accessible.
• Some embedded code snippets in blog posts are styled with monospace and may exceed the comfortable scanning width on very small viewports; horizontal scrolling is provided but not ideal.
• A small number of older iOS apps in our catalog (those released before mid-2025) have less complete VoiceOver coverage than newer releases. We bring each one up to current accessibility parity during regular maintenance releases.

5. Reporting an issue

If you encounter a barrier - on this website or inside any of our iOS apps - please let us know. Email [email protected] with subject prefix [Accessibility] and include:

• The URL or app name where the issue occurred.
• The device, operating system version, and assistive technology you were using (e.g. iPhone 17 with VoiceOver, MacBook Pro with Safari).
• A short description of what happened and what you expected.

We treat accessibility reports as priority bugs. Acknowledgement within 24 hours, fix or workaround within one to two release cycles.

6. Ongoing testing

We run accessibility audits on every major release using a combination of:

• Manual testing with VoiceOver on iOS, macOS Safari, and TalkBack on a borrowed Android device.
• Automated checks against WCAG 2.1 using Xcode Accessibility Inspector and Lighthouse for the web.
• Real-user feedback through the channel above.

7. Formal complaints

If you are unhappy with our response to an accessibility report, you may escalate the matter to the relevant national authority. In the European Union, this is typically the body responsible for enforcing the Web Accessibility Directive in your country; in the United States, you may contact the Department of Justice (Civil Rights Division).

8. Contact