Accessibility Statement

Draft pending deployment testing and operator review. This statement describes accessibility objectives and a proposed feedback process for the supplied site. It is not a declaration that every page conforms to a particular standard. The operator must test the actual installation, document known barriers, identify a responsible contact, and review any applicable legal statement requirements before publication. A theme’s design intentions do not establish the accessibility of edited content, added plugins, or the deployed service.

Our accessibility objective

The site aims to make loot-filter tools and explanations usable without requiring precise pointer movement, color perception alone, or unnecessary motion. Clear headings, labeled controls, readable text, visible keyboard focus, and understandable errors support that goal. Accessibility is part of the usefulness of the toolkit: a technically correct result is not useful if a person cannot enter the input, find the result, or understand a limitation communicated only by color.

The Web Content Accessibility Guidelines provide an important reference for review, including relevant Level AA criteria. Referencing that framework is not the same as claiming audited conformance. A reliable conformance statement requires a defined scope, method, date, and evidence. This draft does not invent an external audit, certification, disabled-user testing program, or list of assistive technologies that were supposedly checked.

Navigation and reading

Public pages are intended to use a logical heading structure and a single page-level heading. Navigation should expose meaningful links, and menus should be operable by keyboard rather than depending only on hover. A skip link and visible focus treatment help users reach the main content without repeating every navigation item. Editors need to preserve these structures when adding content rather than choosing heading levels solely for visual appearance.

Text should remain readable when enlarged, and layouts should adapt to narrow screens without hiding essential controls. Long code examples and comparison tables may need their own scroll areas, but the surrounding page should not force unnecessary horizontal navigation. Browser zoom, text-size settings, and reader modes can be useful alternatives. The operator must check that these settings do not obscure form actions, dialog controls, or important explanations in the deployed layout.

Interactive tools and status messages

Tool controls should have visible labels and programmatic names that describe their purpose. Related choices should be grouped clearly, and input errors should identify the field and a useful correction. Results that change after a button press should be announced or placed where users can find them without searching the entire page. A loading state should not leave a keyboard user unable to determine whether work is continuing, complete, or blocked by an error.

File pickers, copy actions, downloads, worker-based processing, and browser storage depend on browser capabilities and permissions. Where a feature cannot run, the interface should explain the limitation rather than silently failing. Static instructions should remain readable without JavaScript, but the interactive analysis itself may require scripting. A no-script explanation is not equivalent to a complete alternative implementation, and this statement must not imply otherwise.

Color, sound, and motion

Important messages should use text or another meaningful cue in addition to color. The interface should not rely solely on a red or green result marker to distinguish errors from success. Tool previews need the same care: a color-vision simulation is an approximation, and a contrast ratio does not establish that every player can read the resulting in-game label. Users should be able to inspect the underlying values and explanations rather than relying only on the visual sample.

Motion should be limited and should respect a preference for reduced motion where the interface uses animation. Audio must not be the only means of understanding an important result. For generated filters, the site recommends redundant visual and sound cues but cannot guarantee the accessibility of the game client’s rendering or a user’s chosen custom sounds. Those are separate environments that require practical testing.

Forms, privacy, and alternative assistance

The contact form should identify required fields, provide understandable validation, and make success or failure messages available to assistive technology. Anti-abuse measures can introduce barriers, especially if an optional third-party challenge is enabled. The operator must review those measures and provide a reasonable alternative communication route rather than assuming that every visitor can complete the same challenge. A direct contact route must be real and configured, not an invented mailbox.

When requesting assistance, describe the page, control, action attempted, and difficulty encountered. Include the browser and assistive technology only if you are comfortable sharing them and believe they are relevant. A medical diagnosis or proof of disability is not required to report a barrier. Avoid sending account credentials, full device logs, or other sensitive information when a brief description is sufficient.

Known limits and the need for testing

No completed deployment-specific accessibility audit is represented by this starter statement. Areas requiring careful review include mobile menus, keyboard focus after dialogs close, long comparison results, live status announcements, color controls, file-drop alternatives, and contact errors. Automated checks can find some issues, such as missing labels or certain contrast failures, but cannot establish whether an explanation makes sense or whether a complete keyboard workflow is practical.

Manual review should include keyboard-only use, zoom and reflow, reduced-motion settings, representative screen-reader tasks, and error recovery. Test real content and long inputs, not just empty forms. Record the browser and assistive technology versions actually used. Any remaining barrier should be described with its impact and an available workaround, if one exists, without inventing a repair deadline that the operator cannot support.

Feedback and ongoing review

Use Contact to report an accessibility concern once a working recipient has been configured. State your preferred format or communication method if you need the same information another way. If the form itself is inaccessible, use a displayed alternative contact route where available. The operator must ensure that at least one effective channel exists before launch; this draft does not substitute for that operational step.

Reports should be prioritized according to the barrier’s impact, availability of alternatives, and reproducibility. Responses and fixes depend on the issue and available resources, so no guaranteed turnaround is stated. Review accessibility after significant theme, content, plugin, or service changes. The Editorial Policy also applies to accessibility claims: communicate what was actually tested, acknowledge unresolved issues, and correct misleading statements rather than presenting aspirations as evidence.