Accessibility statement

TaleArt aims for WCAG 2.2 level AA. This page says what that covers, what the project's own checks show, what is known to fall short, and how to report a problem. Statement of 31 October 2026.

This is a self-assessment by the owner, a single developer. No independent audit has been done, and the text is not legal advice.

1. Target and status

The target is the Web Content Accessibility Guidelines (WCAG) 2.2, level AA. TaleArt is partially conformant: the automated checks below pass, some criteria cannot be checked by a script and have been checked by hand only on some screens, and the known gaps in section 4 remain.

2. What is covered

3. What the checks show

• Documentation site: every docs page, including the three legal pages, has no violation of the axe-core WCAG 2.2 AA rules in the light and the dark theme in Chromium, when this statement was written.
• Dashboard: the scan above is part of the repository and is meant to be run before a release. It was not run again for this statement, so this statement makes no claim about its latest result.
• Contrast. The design rule for the SDK is text at 4.5:1 or better on any background. Text on an accent colour picks white or dark automatically. The docs and the dashboard use text and focus colours that axe-core accepts in both themes.
• Target size. The web viewer's controls are 44 px; its dots are 24 px targets. The bar layouts set a 44 px minimum height. The native viewer's controls are 48 dp targets with a 44 dp visible disc. The dashboard is checked for the 24 by 24 px minimum of WCAG 2.2 criterion 2.5.8.
• Right-to-left. The web SDK uses logical CSS properties, mirrors arrows, progress and carousels, and keeps numbers, percentages and countdown digits left-to-right. The native SDK uses the platform's layout direction. The Android guide shows a Hebrew right-to-left viewer.
• Motion. The motion in the viewer, bar and components stops under prefers-reduced-motion on the web and under the Reduce Motion setting on iOS. On Android the SDK follows the system's "Remove animations" setting (animation scale off).
• Screen reader actions. The Rating component has a "Send rating" action that a screen reader user can run without dragging; the viewer announces the tale's progress in a polite live region on the web.
• Keyboard. The docs site has a skip link, a labelled landmark structure, visible focus, a menu button that works by keyboard, and moves focus to the page heading after a navigation. The dashboard's menus, tabs, switches and reordering are checked by keyboard in the scan above.

4. Known gaps

These are known, and the owner does not claim otherwise:

• No real screen reader testing on devices. TalkBack on Android and VoiceOver on iOS were not used to walk the native SDKs. The Web SDK and the dashboard were not walked with NVDA, JAWS or VoiceOver either. Semantics are set in the code and unit tested, but how they sound has not been verified.
• Automated checks run in Chromium only. Firefox, Safari and mobile browsers are not scanned.
• Native sizes and contrast are not measured on devices. The Android and iOS SDKs have been reviewed in source and not tested on a wide range of devices. The frosted backdrop blur behind the viewer controls is not drawn natively, so a plain translucent disc is used there, and its contrast was not measured on real media.
• The desktop viewer shows neighbouring tale groups beside the current one. Those neighbours are not scanned separately from the current tale, and their reading order has not been checked with a screen reader.
• Android Reduce Motion is all or nothing. The Android SDK reduces motion only when the system's animation scale is switched fully off. A reduced but non-zero scale does not change the SDK's motion.
• Customers' content. A tale is the customer's images, video, text and colours. TaleArt cannot write alternative text, captions, transcripts or good contrast for them. The customer is responsible for the content, and for running the SDK in a way that fits their own accessibility duties.
• The API reference uses the third-party Swagger UI. It passes the scan and was patched to label its controls, but it is not as polished as the rest of the site.
• Limited criteria by hand. Criteria that scripts cannot judge (meaningful sequence, consistent help, clear error text, drag alternatives) have been checked by hand on some screens only.

5. Report a problem

If something in the docs, the dashboard or an SDK is hard or impossible to use with your assistive technology, please open an issue at GitHub issues with the title "Accessibility", the page or screen, what you tried, the browser or device, and the assistive technology you use. Do not put personal data in a public issue.

The owner will try to acknowledge a report within 14 days and to fix real barriers as time allows. This is a best-effort project with a single maintainer, so no fixed response time is promised. If you do not get a satisfactory answer, you may contact the relevant authority in your country (in Israel, the Commission for Equal Rights of Persons with Disabilities).

6. Date

This statement was written on 31 October 2026, from the code and tests in the repository on that date. See also the Terms of service and the Privacy policy.