Animiyo accessibility statement

A platform that stores health records, doses, vaccination due dates and treatment reminders cannot afford barriers. People caring for a sick animal often do so in difficult conditions: in a hurry, with one hand busy, on a small screen, with tired eyes or in a poorly lit room. The same choices that serve a person with a permanent disability also serve anyone in a temporary difficulty or in a demanding situation.

This statement covers the public site and the Next.js web application hosted on Google Cloud Run and reachable from the platform domain. It does not cover the native iOS application, which follows the accessibility guidelines of the operating system and will be covered by a separate statement once its assessment is complete. It does not cover third party sites that outbound links may lead to.

The document is written to be useful, not reassuring. Where a feature is missing we say so, where an alternative exists we point to it, where there is no alternative at all we write it plainly. An accessibility statement that hides its own limitations only serves the party publishing it.

The technical reference adopted is the WCAG 2.2 guidelines at level AA from the World Wide Web Consortium. They are the common destination of both the European harmonised standard and Italian law, so working on the WCAG criteria means working on every applicable framework at once.

The four sources are not alternatives to one another. The WCAG provide the testable criteria, EN 301 549 places them in the European framework, legislative decree 82/2022 establishes the obligation for services aimed at consumers, and the Stanca law defines the national context and the supervisory bodies.

Animiyo declares partial conformance with the WCAG 2.2 guidelines at level AA. Partial conformance means that part of the content and functionality meets the required criteria and part does not. This is not a polite formula: the non conforming parts are the ones listed in the section on known limitations, set out one by one with the specific limitation and any alternative available.

The declared status comes from a self assessment carried out by the owner of the project and completed on 2 August 2026. There is no third party certification, no independent audit has been performed and no conformance score or percentage is claimed.

• What was assessed: the public pages of the site, the legal documents, the editorial content pages and the main screens of the web application.
• What was not assessed: the native iOS application, the documents uploaded by users and clinics, the content generated by users.
• Who assessed it: the owner of the project, with no external assessor involved.
• When: 2 August 2026.

The statement will be updated when the planned actions are completed, or when a substantial change to the platform alters the picture described here. The document version and the revision date are shown at the top of the page.

The features listed below are already active in the platform. Some are always present and need no action, others are enabled from the appearance settings and then stay in force for later visits.

1. 1

   Open the appearance settings

   The appearance preferences gather theme, contrast, text scale, type family and reduced motion in a single place. You do not need to change anything in the browser or in the operating system.

2. 2

   Choose the theme and the contrast level

   The theme can be light, dark or set by the system, so that it follows the device setting automatically. High contrast mode is independent of the theme and is switched on separately.

3. 3

   Adjust the text scale and the typeface

   The three scales available are small, medium and large, and none of them causes loss of content or functionality. The type family can be chosen between a neutral sans, a grotesque and a serif face.

4. 4

   Switch on reduced motion if you need it

   With reduction active, animations are kept to a minimum. Animations also respect the system preference prefers-reduced-motion, so anyone who has already set it at operating system level does not need to repeat the choice here.

5. 5

   Check that the preference follows you

   Settings are saved in the animiyo.appearance key of browser local storage. If you have an account and are signed in they are also saved in your profile, so they follow the person across devices instead of staying tied to a single browser.

An inline script applies the preferences before the first paint of the page. It exists to avoid the flash caused by switching from the default theme to the chosen one, which for many people is merely a cosmetic flaw but for anyone with light sensitivity is a real disturbance.

The editorial content and legal documents of Animiyo are not written in raw HTML. They are composed of typed blocks: paragraphs, lists, tables, callouts, steps and quotes. The renderer turns every block into semantic markup, always in the same way.

• The heading hierarchy is generated by the model, so there are no level jumps caused by a typographic choice made by the author.
• Table headers are declared as such and associated with their cells, so a screen reader can announce which column a value belongs to.
• Lists are real lists and not lines separated by symbols, so assistive technology announces their length and the current position.
• Callouts carry a declared title and tone, so meaning is never left to colour alone.
• Since there is no raw HTML in the content files, there is no markup improvised case by case.

Every content page has a section index with stable anchors. The index makes it possible to reach a section without scrolling through the whole document, and the anchors do not change when the text is updated: a deep link shared with another person keeps working even after a revision.

This model removes defects at the root. A structural accessibility defect almost always comes from one wrong manual choice repeated many times; by moving structure into the data model, the mistake becomes impossible for the author to make, because the compiler rejects a malformed block and the renderer always produces the same markup. Content mistakes remain possible, for example an alternative text that describes little, but structural mistakes do not.

Animiyo publishes nine languages: Italian, English, French, Spanish, German, Simplified Chinese, Estonian, Russian and Arabic. The codes used in the routes are it, en, fr, es, de, zh-Hans, et, ru and ar.

• Arabic is rendered with text direction from right to left, with the dir attribute set on the root element of the page, so the direction applies to the whole interface and not only to paragraphs.
• Every page declares its own language, so the speech synthesis of a screen reader uses the correct pronunciation instead of reading foreign text with the rules of the wrong language.
• Dates and numbers follow the local conventions of the chosen language, rather than a single format imposed on every version.
• The hreflang annotations list only the versions that are actually translated: a page that has not been translated is never announced as available in that language.

Language coverage is a matter of accessibility before it is a matter of market: reading health instructions in a language you do not command is as much a barrier as insufficient contrast. The current limitation is the quality of the review, not the coverage: translations in languages other than Italian and English have not yet been reviewed by a native speaker for the clarity of the label text.

The platform is built to work with assistive technology, but the testing actually carried out does not cover every possible combination. Below is what was tested and what was not, because without that distinction a compatibility claim has no practical value.

• Tested: navigation using the keyboard alone on the public pages and on the main screens of the application, checking that the focus indicator stays visible at all times and that no element becomes unreachable.
• Tested: text magnification up to two hundred per cent, checking that content stays readable and functions stay operable.
• Tested: right to left rendering of the Arabic version, including the direction of the navigation elements.
• Tested: heading structure and form labels on the main pages.
• Not tested systematically: combinations of screen reader, browser and operating system. The checks carried out were partial and do not cover every screen.
• Not tested: voice control, alternative keyboards and assisted pointing devices.
• Not tested: the PDF documents and images uploaded by users and clinics, which go through no accessibility check at all.

Declaring which combinations were not tested is part of the statement itself. Without that information a person cannot know whether their own tool was taken into account, and finding out in practice means losing time on a service that manages health deadlines. Testing with screen readers across more combinations of operating system and browser is among the planned improvements.

These are the limitations we know about at the date of the assessment. They are listed in full, with the alternative available where one exists and with an explicit statement that none exists where that is the case.

None of these limitations is presented as marginal. Walk maps and uploaded documents are concrete barriers for anyone using a screen reader, and until they are resolved conformance stays partial.

The assessment is a self assessment carried out by the owner of the project. There is no third party certification, there is no independent audit and no external party has verified the conclusions set out in this document.

1. Automated checks on the main pages of the site and the web application.
2. Manual navigation testing using the keyboard alone.
3. Verification of contrast ratios between text and background.
4. Testing with text magnification up to two hundred per cent.
5. Review of the heading structure and of the form labels.
6. Verification of right to left rendering in the Arabic version.

Date of the assessment: 2 August 2026. The results refer to the version of the platform published on that date.

A self assessment has a structural limitation that should be stated: whoever built the interface is also the one judging it, knows the paths that work and tends to follow them. For this reason considering an independent audit is among the planned improvements, before opening to the public.

If you run into a barrier you can report it from the Contacts page of the site, at the path /contatti. Every report is useful even when it concerns a limitation already listed in this document, because it shows how much weight that limitation carries in real use.

1. 1

   Open the Contacts page

   The /contatti page of the site opens an email with a ready made subject line addressed to the address shown there. There is no form to fill in and you do not need an account to write.

2. 2

   Give the address of the page

   Copy the full address of the page where you met the problem. Without the address the check takes far longer and sometimes the situation cannot be reproduced at all.

3. 3

   Describe the browser and the assistive technology

   State which browser and which assistive technology you were using, with the version if you know it. The same page can behave differently depending on the combination, so this detail is often decisive.

4. 4

   Tell us what did not work

   Explain what you were trying to do and what happened instead. If you can, say what you expected to happen: the gap between expected and obtained is the most useful piece of information.

A reply arrives within thirty days of the report. If the reply is not satisfactory or does not arrive, in Italy it is possible to submit a report to the Agency for Digital Italy, which supervises the application of accessibility legislation. For services falling within legislative decree 82/2022 it is possible to address the designated supervisory authorities. Judicial protection remains available in any case.

The actions listed below are the ones decided in order to overcome the declared limitations. They are ordered by priority and concern both the features and the method by which accessibility is verified.

Priorities reflect the severity of the barrier, not how easy the work is. No delivery date is promised in this document: when an action is completed the statement is updated, the version changes and the matching row leaves the list of known limitations.