Accessibility Statement

Mr. Blindbandit and Blindbandit Records are committed to making mrblindbandit.net usable by people with disabilities, including people who use screen readers, keyboard navigation, magnification, voice control, captions, reduced motion, high contrast, and other assistive technologies.

The operator, Kaeleb Savon Heck, is himself a blind screen-reader user. Accessibility is therefore treated as a product requirement rather than a cosmetic add-on.

Our development target is WCAG 2.2 Level AA. This is a commitment to improvement, not a claim of verified full conformance. Production testing with physical devices and screen readers remains necessary, including iOS VoiceOver and Safari.

The site should maintain a skip-to-main-content mechanism, logical headings, semantic landmarks, labeled form controls, descriptive links and buttons, useful alternative text for informative images, keyboard operability, visible focus, sufficient contrast, scalable text, reflow support, reduced-motion behavior, and status/error communication that assistive technologies can perceive.

Accessibility controls such as larger text, high contrast, and pause motion should complement rather than replace standards-compliant underlying code.

Core public tasks should be tested with iOS VoiceOver and Safari because that is a primary real-world use case for the operator. Additional testing should include macOS VoiceOver and, where feasible, NVDA with current desktop browsers. Interactive controls should expose correct roles, names, states, values, and relationships without depending on visual position.

Every interactive function should be reachable and operable by keyboard without requiring a mouse or touch gesture. Focus order should follow the task, focus should remain visible, modal dialogs should move focus appropriately and return focus on close, Escape should close dismissible dialogs when expected, and hidden background content should not remain focusable behind an active modal.

Sticky headers, cookie banners, bottom drawers, media controls, accessibility panels, and chat-style overlays must not completely hide the currently focused component. This is particularly important under WCAG 2.2 success criterion 2.4.11.

A feature that uses dragging should provide a non-drag alternative unless dragging is essential. Media Suite timelines, clip ranges, crop regions, sliders, artwork positioning, and waveform selections should therefore provide labeled keyboard-accessible or numeric controls. This addresses WCAG 2.2 success criterion 2.5.7.

Pointer targets should meet WCAG 2.2 Level AA minimum target-size or spacing requirements. Small icon buttons, close buttons, playback controls, poll actions, menu items, and Media Suite handles should be reviewed against success criterion 2.5.8.

Authentication must not force a cognitive-function test such as memorizing or transcribing information without an allowed alternative. Password managers and copy/paste should not be unnecessarily blocked. One-time-code workflows should have clear labels and support accessible input. CAPTCHA, if used, must provide an accessible alternative. These requirements support WCAG 2.2 success criterion 3.3.8.

Each field needs a programmatic label. Required state, format guidance, and errors should be exposed in text rather than color alone. After failed submission, focus or an error summary should help users locate the problem, and status messages should be announced without unexpectedly stealing focus.

File-upload controls should identify accepted formats and meaningful size limits in accessible text. Upload progress, successful completion, and failure should be announced appropriately.

Normal text, large text, meaningful graphical objects, focus indicators, and user-interface components should meet applicable WCAG contrast criteria. Content should remain usable when text is enlarged to 200 percent and when the page is reflowed at narrow viewport widths consistent with WCAG requirements. Users should not have to perform two-dimensional scrolling for ordinary reading at the required reflow test size except for content that inherently needs it.

The site should honor reduced-motion preferences where applicable. Auto-moving content must provide controls when WCAG requires them. The site's Pause Motion control must not be the sole protection against motion that should have been coded accessibly by default.

Prerecorded video with meaningful speech should provide captions when required. Audio-only material should provide an appropriate text alternative where required. Visual-only information important to understanding a video may require audio description or another equivalent accessible alternative. Automatically generated captions should be reviewed when accuracy is important.

Informative images require meaningful text alternatives. Decorative images should be ignored by assistive technology. Icon-only controls require an accessible name. Decorative arrow glyphs or external-link symbols should not make a link's spoken label confusing or repetitive.

Post composers, comments, polls, menus, dialogs, notifications, vote changes, form errors, and moderation messages should use semantic HTML and carefully scoped live regions. The interface should not announce excessive background updates or repeatedly interrupt a screen-reader user.

Waveforms, meters, timelines, canvases, and crop areas cannot be the only control model. Every critical value must have a text representation. A blind user should be able to select a file, inspect metadata, choose presets, enter clip times, select a normalization target, start processing, hear progress or status changes, identify errors, and obtain the output without relying on a visual graph.

Cookie and privacy dialogs must themselves be keyboard and screen-reader accessible. Buttons should have understandable names; consent and refusal options must be reachable; focus must not escape invisibly behind the dialog; and a user must be able to reopen privacy choices later.

The page must identify its primary human language programmatically. If a language switcher changes the document language, the html language attribute should change as well so screen readers use appropriate pronunciation rules.

Third-party embeds can have accessibility limitations outside the operator's direct control. Where practical, the site should provide a clearly labeled direct link or alternate way to reach the same content. Third-party limitations should not be used as an excuse to leave the site's own controls inaccessible.

Accessibility issues are tracked with the affected task, severity, remediation and review evidence. Automated checks do not establish full conformance. Contact the Accessibility Coordinator if you encounter a barrier or need an alternative way to complete a task.

Accessibility barriers may be reported to accessibility@mrblindbandit.net. Reports should identify the page, feature, browser or assistive technology if known, and the problem encountered. The operator should acknowledge meaningful reports, prioritize blockers, and communicate when a correction or workaround is available.

Kaeleb Savon Heck serves as Accessibility Coordinator for mrblindbandit.net and is responsible for coordinating accessibility review, remediation priorities, and feedback handling.