Accessibility Statement
Last updated: 19 September 2026.
1. Commitment and standard
JoelKlemmer.com is intended to be usable by people with disabilities, including people who use keyboards, screen readers, magnification, voice input, switch devices and alternative display preferences. Joel R. Klemmer, United States, is responsible for the website and for receiving accessibility concerns at contact@joelklemmer.com.
Our technical target is the Web Content Accessibility Guidelines, version 2.2, Level AA. We also apply selected Level AAA practices where they improve the experience and can be supported consistently. “AA+” is sometimes used informally, but it is not a separate WCAG conformance level. We do not use it as a certification or represent that the website has achieved every Level AAA success criterion.
Accessibility is part of design, content, development and release review. A visually immersive experience should not require animation, a three-dimensional renderer, a particular color theme or a pointer device to reach essential information. Accessibility controls supplement semantic HTML and usable default behavior; they do not replace the need for an accessible underlying site.
2. Scope of this statement
This statement covers the pages and interface operated at JoelKlemmer.com, including navigation, search, book information and retailer directories, public source records, recognition, media and press resources, contact, policy pages and the AI guide. It addresses the content and functions we control.
Independent retailers, publishers, social networks, podcast platforms and other linked services control their own interfaces and materials. Their accessibility can differ from this website. A link to a third-party service does not certify its accessibility. If an external resource creates a barrier to information available here, tell us what you need and we will consider an appropriate alternative within our control.
Downloadable documents, images and audiovisual material have format-specific considerations. A visual PDF may behave differently from its HTML presentation, particularly with reading order, tagging, text extraction and assistive technology. We do not treat a visual review or successful PDF download as proof of PDF/UA conformance. The website’s HTML presentation of media and press information provides a separate reading path; contact us if that path does not meet your needs.
3. Navigation and keyboard use
The website uses landmarks, headings, meaningful link text, native links and form controls to support navigation with assistive technology. A skip link provides a route to the main content. Keyboard focus is intended to remain visible and follow a meaningful order. Navigation dialogs support keyboard entry and dismissal, and closing a dialog should return focus to its invoking control when that control remains available.
Use Tab and Shift+Tab to move between controls, Enter to activate links and buttons where supported, and Escape to dismiss an open dialog. Native controls may also support arrow keys or Space according to the browser and assistive technology. We do not intentionally replace familiar browser shortcuts or require a complex gesture for an essential action.
Pointer targets are designed with sufficient size and separation. An action that is available on hover should also be discoverable and operable through a keyboard or other supported input. Touch, keyboard and pointer presentations may differ in layout while preserving the same essential content and actions.
4. Display, contrast, motion and graphics
Theme settings allow a light, dark or system-selected presentation within the same visual direction. Text, controls and focus indicators are reviewed for contrast against their actual backgrounds. Decorative images and layered surfaces must not make essential text depend on an unpredictable background for readability. Color alone should not identify an error, status or selected state.
Motion settings allow a reduced-motion presentation and can follow the operating system’s preference. Essential content should remain available when motion is reduced. The graphics setting provides a lighter presentation for visitors who prefer or require reduced rendering. If the browser cannot support a three-dimensional scene, a static presentation should preserve the information and navigation needed to use the site.
You can zoom and use browser text-size preferences. Layouts are reviewed for reflow and for loss of content when text or viewport dimensions change. Some visual objects, such as a book cover or publication page, retain an intrinsic shape; alternative text and surrounding HTML information provide context independently of the image’s physical layout.
Display preferences are stored on the device only when the optional remember-settings control is selected. You can clear that choice through the interface. Failure of browser storage should leave usable defaults rather than prevent access. The Cookie Policy explains this storage separately.
5. Text, structure and language
We aim to use clear headings, readable text sizes, sufficient line spacing and meaningful reading order. Information should not depend on visual position, shape or an instruction such as “click the item on the right” alone. Forms and interactive elements should expose understandable names and relationships to assistive technology.
The site provides 50 language choices. Language attributes and writing direction are used so browsers and assistive technologies can interpret the selected language and right-to-left text appropriately. Names, original book titles and quotations may remain in their source language where translating them would misidentify the work; surrounding explanations should make that distinction clear.
A translated interface is not automatically an accessible or accurate one. Long labels, non-Latin fonts, bidirectional text, local date formats and translated instructions require separate checks. If a translation makes a control or explanation unclear, identify the language and page in your report. We will assess both the meaning and the resulting usability.
6. Images, books, publications and media
Meaningful images should have text alternatives that convey their purpose. Decorative imagery should not create repetitive announcements or obscure meaningful content. Photographs and generated scenes should not carry essential facts that are unavailable in nearby text. Book titles, authorship, editions and purchase information are presented as text rather than relying solely on cover images or three-dimensional objects.
Media and press publications have HTML reading interfaces as well as downloadable versions. Controls should be named, keyboard operable and usable when motion is reduced. Text zoom, page navigation and source links should remain available without requiring a page-turn gesture. If a particular reader or document format is a barrier, request the information in another suitable format.
Where we publish meaningful prerecorded audio or video under our control, accessible alternatives such as captions, transcripts or descriptions are required as appropriate to the content and applicable standard. Decorative motion with no additional information can use an equivalent static presentation. Third-party recordings may have captions or transcripts supplied by their host; we do not assume that those features are present or accurate merely because the recording is linked.
7. Forms, errors and automated answers
The contact form identifies required fields and provides validation feedback. Errors should be expressed in text and associated with the affected control or a navigable summary. Submission progress, success and failure should be communicated to assistive technology without relying solely on color, animation or a transient visual message.
The AI guide is optional. Ordinary search, source pages and contact remain available independently. Its question field, submission, cancellation, result and error states are intended to be keyboard and screen-reader accessible. Generated answers are displayed as text with source links. A failure or unsupported question should produce a clear explanation rather than an empty result presented as success.
AI output can be wrong or difficult to understand. It does not replace a requested accessibility accommodation or direct assistance. You may ask for information through the contact channel instead of using an AI provider. The AI Policy and Privacy Policy explain the feature’s limitations and data handling.
8. Evaluation and current limitations
We use a combination of source review, automated checks, keyboard testing, responsive browser checks and visual inspection during development and release preparation. Automated tests can identify certain defects but cannot establish that every interaction works for every person or assistive technology. A successful test on a simulated viewport is not the same as testing a physical phone, television, VR headset or every embedded browser.
Our approach is to make essential information available through standard web controls and text so that decorative scenes do not become a barrier on constrained devices. Actual behavior can still vary with operating system, browser, assistive technology, hardware, network, font support and user settings. If a combination fails, we want the specific information needed to reproduce the barrier and provide an alternative.
We do not claim third-party accessibility certification, complete Level AAA conformance, universal physical-device testing or accessible third-party content without supporting evidence. Downloadable documents and hosted external media require their own evaluation. A known limitation must be assessed and addressed through a correction or an appropriate accessible alternative, not dismissed solely because an automated report passed.
9. Requesting assistance or an alternative format
Email contact@joelklemmer.com or use the contact form to report a barrier or request information in an accessible format. If the form itself is difficult to use, the email channel is an alternative. You do not need to disclose a diagnosis to make an accessibility request.
Useful details include the page address, the information or action you were trying to access, the barrier encountered, the device and browser, any assistive technology involved, and the format or assistance that would help. Share only what is necessary; do not send passwords, medical documents or unrelated private information. You may omit technical details you do not know.
We aim to acknowledge an accessibility request within five business days and provide a substantive response or a practical next step within ten business days. Some corrections or alternative formats may require more time; in that case we aim to explain the expected next step and keep you informed. A shorter deadline or different procedure required by applicable law takes precedence. These targets are not a promise that every software defect can be permanently resolved within that period.
Reasonable assistance should not require you to use the feature that created the barrier. Depending on the request, an appropriate response may be a text version, a document in another format, a clarified link, assistance locating a source or a correction to the interface. We will consider the requested form of assistance and the obligations that apply to the circumstances.
10. Feedback, escalation and legal rights
If a response does not resolve your concern, reply with the outstanding barrier and ask for a further review by the website operator. Keep the relevant dates and correspondence if you need a record. Accessibility correspondence is handled under the Privacy Policy and the applicable retention rules.
This internal process does not limit your right to contact an accessibility, disability-rights, consumer-protection or other competent authority, use an available complaint process, or seek a remedy under applicable law. You do not have to give up a statutory right to obtain assistance. No disclaimer elsewhere on the site excludes a duty that cannot lawfully be excluded.
Accessibility requirements vary between countries and, in the United States, between federal, state and other applicable legal frameworks. WCAG is a technical standard; its use does not by itself decide which law applies to this website or certify compliance with every local requirement. Mandatory applicable protections control where they require more than this statement describes.
11. Maintaining and updating accessibility
We review accessibility when adding a feature, changing navigation, updating a publication, introducing a new asset or translating content. The relevant checks should include the actual interaction and meaningful failure states, not only a static screenshot. Significant changes to the AI guide, publication readers or scene controls require renewed review of the affected functions.
We will update this statement when a material change affects the features, limitations or assistance described here. The date on the published page identifies the version. Contact Joel R. Klemmer, United States, at contact@joelklemmer.com for assistance or further information.