Accessibility Policy
Last Updated: April 1, 2026
Section 1. Basic Policy
We position SmoothQ as a service with strong public utility and aim to keep necessary information reachable regardless of age, disability, device, communication environment, or temporary constraints. Accessibility is treated not as an optional add-on but as a quality requirement to be addressed in design, implementation, operations, and continuous improvement.
Section 2. Scope
This Policy applies to principal public pages under https://smoothq.jp/, including search, map pages, inquiry pages, legal notices, and other key user-facing screens we directly manage. Content or components that are controlled by third parties, legacy assets, or external platforms may not be fully remediated immediately, but we seek to reduce practical disadvantage and provide alternatives where reasonably possible.
Section 3. Target Conformance Level
We refer to JIS X 8341-3:2016 and WCAG 2.2 and target Level AA-equivalent accessibility for major public functions as a general rule. Where technical constraints exist, especially around real-time maps, third-party integrations, or embedded components, we use staged remediation, alternative paths, or managed exceptions to minimize material disadvantage to users.
Section 4. Legal and Public Guidance
This Policy is informed by the Act for Eliminating Discrimination against Persons with Disabilities, the Act on Promotion of Information Accessibility and Communication for Persons with Disabilities, the Ministry of Internal Affairs and Communications public website guidelines, materials published by the Digital Agency, and related public guidance. We consider both the legal concept of reasonable accommodation and the practical requirements of web accessibility standards.
Section 5. Information Architecture and Readability
We aim to design headings, landmarks, link labels, tabular information, status indicators, error messages, and important notices so that they are understandable not only visually but also when used with assistive technologies. We avoid conveying meaning by color alone and use headings, context, icons, and text explanations together as appropriate. We strive for clear and concise language and add supporting explanations where legal or technical descriptions would otherwise be difficult to understand.
Section 6. Keyboard Operability
Core functions should remain usable through keyboard-only navigation, selection, submission, and dismissal. Focus order is designed to align with the visual and functional flow, and visible focus indication is maintained. For more complex components such as dialogs, menus, and map controls, we aim to provide focus management, exit paths, and alternative routes so that keyboard users do not become trapped or blocked.
Section 7. Visibility and Display Adjustments
We consider contrast ratio, text resizing behavior, line wrapping on narrow screens, and loss of information at enlarged scale. Even when users rely on browser zoom, operating system scaling, dark mode preferences, or font substitution, we aim to preserve access to important information and core controls. Where we provide our own font-size settings, we also consider persistence, reversibility, and ease of use.
Section 8. Alternative Text and Non-Text Content
Images, charts, icons, maps, status badges, and other non-text elements are provided with alternative text, labels, adjacent explanation, or other equivalent treatment depending on their role. Purely decorative content is not given unnecessary spoken descriptions. Where maps or other visual representations are central, we strive to make facility names, locations, and wait-time information available through textual alternatives or adjacent content.
Section 9. Forms, Input Support, and Error Prevention
On inquiry, login, and similar forms, we label controls, identify required items, indicate input expectations, and explain error reasons and how to correct them in a manner that remains understandable to assistive technology users. Validation is performed before and/or after submission as appropriate, and time limits or token expiry should be paired with reasonable notice or reacquisition methods when feasible.
Section 10. Compatibility and Verification
We periodically verify major journeys across widely used browsers, mobile environments, keyboard-only use, and assistive-technology-like conditions. Automated checks alone are not treated as sufficient; human review is also used for heading structure, alternative text, focus flow, reading order, form submission, and dialog interaction. Additional checks are performed after major releases, significant UI changes, and serious incidents.
Section 11. Exceptions
Third-party libraries, external map tiles, externally hosted PDF files, and certain legacy materials may be managed as exception items where immediate full remediation is not practicable. Such exceptions are recorded together with impact, priority, alternative arrangements, and remediation outlook. An exception does not eliminate our improvement duty; rather, it helps us prioritize the most harmful issues first.
Section 12. Feedback and Improvement Flow
Reports concerning inaccessible content, missing alternatives, keyboard difficulties, unreadable areas, or similar concerns may be submitted through our inquiry window. We classify each report, assess severity, reproducibility, user impact, and legal implications, and route it to the responsible team. Under normal circumstances we aim to provide an initial response within ten business days and, where remediation is required, explain our planned response or expected timeframe.
Section 13. Alternative Support in Critical Situations
Where a major issue, outage, or known accessibility defect prevents a user from reaching essential information, we endeavor to provide reasonable alternative assistance through our contact channel, including textual guidance, supplemental explanation, or alternate confirmation steps. In particular, if access to facility or public-service information is materially disrupted, we seek to guide users toward substitute confirmation paths through site structure or support contact points.
Section 14. Continuous Improvement
We conduct quarterly self-checks, review major releases, analyze incoming feedback, and revisit design standards so that accessibility quality improves continuously rather than sporadically. Findings, unresolved issues, and priority decisions may be reviewed internally and reflected back into design patterns, implementation rules, and operational procedures.
Section 15. Contact
If you identify accessibility concerns, have difficulty accessing information, or require an alternative means of obtaining content, please contact us through the contact point below. We will consider reasonable accommodation and provide additional explanation, alternate guidance, or information about planned improvement measures as appropriate.
Operator
JPSM Group Supervising Operations Executive: Haruki Ogasawara Locations: Tokyo / Okayama / Ibaraki Contact: contact@smoothq.jp
SmoothQ: https://smoothq.jp/