Accessibility Statement

01Our commitment

We believe a luxury experience should not exclude anyone. The same care we put into the light of a session (choosing the right hour, the right framing, the right pace) guides how we build the website that introduces our work. Accessibility is not a checkbox we tick once a year; it is a discipline we practise on every page we publish, every image we upload and every form we add.

We are aware that accessibility is a continuous improvement, not a destination. There will always be areas we can refine. We commit to being transparent about both what we have done and what is still pending.

02Conformance status

The Web Content Accessibility Guidelines (WCAG) define requirements for designers and developers to improve accessibility for people with disabilities. They define three levels of conformance: Level A, Level AA and Level AAA. The website at ivaestudios.com is designed to conform with WCAG 2.1 Level AA.

We use the word conformance rather than compliance deliberately. Compliance can imply legal certification by a regulator; we have not pursued formal certification. Conformance describes our honest engineering target: every new page is built and reviewed against the AA success criteria, and existing pages are progressively brought into line.

03Measures we take

To support accessibility, IVAE Studios:

• Builds new pages on a semantic HTML5 foundation, with landmarks (header, nav, main, footer) that screen readers can announce.
• Maintains a visible focus style on all interactive controls so keyboard users can always see where they are on the page.
• Provides a "Skip to content" link as the first focusable element on every page, for users who do not want to tab through the header navigation.
• Tests color combinations against the WCAG 1.4.3 contrast ratios (4.5:1 for body text, 3:1 for large text and meaningful UI).
• Honours the user's prefers-reduced-motion system setting; animation is disabled or shortened automatically when the user has asked the operating system to reduce motion.
• Honours the user's prefers-color-scheme setting through a dark mode that maintains the same contrast targets.
• Writes alternative text for new images that describes the content rather than restating the file name.
• Reviews layouts at viewport widths from 320 px upward so the site is usable on small devices and at 200% browser zoom.
• Treats accessibility regressions discovered in code review or audits as defects, prioritised alongside other defect work.

04Technologies used

The site is built with a deliberately simple stack so it remains robust to assistive technology:

• HTML5 with semantic landmarks and headings.
• CSS3, including CSS custom properties for theming and prefers-reduced-motion / prefers-color-scheme queries.
• WAI-ARIA attributes only where native HTML semantics fall short, for example aria-label on icon-only controls and aria-current on the active navigation item.
• Vanilla JavaScript for progressive enhancements (scroll reveal, language switcher), kept minimal so the page works even if scripts fail.
• Web fonts served from Google Fonts with font-display:swap so text remains readable while custom fonts load.

Accessibility relies on these technologies being supported by the user's browser and any assistive technology in use.

05Compatible assistive technologies

The site has been authored to work with current versions of the following assistive technologies. By current we mean the latest stable release at the date this statement was reviewed.

• VoiceOver on macOS (Sonoma and later) and iOS (17 and later).
• NVDA on Windows 10 and 11.
• JAWS on Windows 10 and 11.
• TalkBack on Android 12 and later.
• Voice Control on macOS and iOS.
• Browser zoom up to 200% without loss of content or functionality.
• Operating system high-contrast modes on macOS, Windows and iOS.

If you use a different combination and run into a problem, please tell us (see Section 10). Coverage tends to be best when the screen reader and the browser are from the same generation.

06Supported browsers

We test against the latest two versions of:

• Google Chrome (desktop and Android)
• Mozilla Firefox (desktop and Android)
• Apple Safari (macOS and iOS)
• Microsoft Edge (desktop)
• Samsung Internet (Android)

Older browsers may render the site with reduced styling but should still expose the underlying content to assistive technology.

07Built-in accessibility features

A few features may help if you are using the site with assistive technology or simply want a calmer reading experience:

• Skip-to-content link: press Tab as soon as the page loads to focus a link that jumps past the header straight to the main content area.
• Language switcher: every page links to its mirror in the other language, with hreflang annotations so search engines and screen readers identify the language correctly.
• Reduced motion: if your operating system reports a preference for reduced motion, scroll-reveal transitions and parallax effects are disabled automatically.
• Dark mode: follows your system preference; the contrast ratios in dark mode also target WCAG AA.
• Resizable text: body text is sized in relative units, so increasing the browser font size flows correctly without breaking layout up to 200%.
• Keyboard navigation: every interactive control is reachable with Tab and operable with Enter or Space. The mobile menu can be opened, navigated and dismissed using the keyboard.

08Known limitations

We would rather be honest than aspirational. Despite our best efforts, the following items are not yet fully conformant. We are working on each of them, and we have shared them publicly so you know exactly where the rough edges are:

• Older blog post imagery. A subset of historical blog post images carries generic alt attributes ("photo by IVAE Studios") rather than descriptive alternatives. We are progressively rewriting these as we revisit each post.
• Lightbox-style image viewer. The full-screen image viewer used in some blog posts works for mouse and touch input but its keyboard navigation is limited to the basic Esc-to-close pattern. We are working on full arrow-key, focus-trap and announcement support.
• Photo galleries are inherently visual. Even with descriptive alternative text, a photograph cannot fully convey light, mood, texture or composition to someone who cannot see it. We try to write alt text that captures subject, action, location and atmosphere, but we acknowledge the limit.
• Embedded social media content. When we embed an Instagram post or a third-party video, we depend on that platform's accessibility, which is sometimes weaker than our own pages. Where possible we provide a textual summary alongside the embed.
• PDF downloads. A small number of older downloadable assets (location guides, outfit guides) were produced before we standardised our PDF accessibility checks. New PDFs are tagged and reading-order tested; older PDFs will be re-exported on a rolling basis.

If you encounter any other barrier we have not listed here, please tell us (see Section 10). Reports help us prioritise.

09Assessment method

The conformance level claimed in Section 2 is based on the following assessment activities, performed during the period leading up to the "Last assessed" date at the top of this page:

• Self-evaluation by the IVAE Studios team against the WCAG 2.1 AA success criteria.
• Manual keyboard testing on the home page, location pages, blog index, a representative blog post, the contact paths and the new legal pages, confirming that every interactive control is reachable, operable, focus-visible and dismissible without a mouse.
• Automated audits using Google Lighthouse and the axe DevTools browser extension, on representative pages from each template.
• Screen reader spot checks with VoiceOver on macOS and iOS, focusing on landmarks, heading order and form labels.
• Color contrast checks against the WCAG 1.4.3 ratio thresholds, using the design tokens defined in dark-mode.css as the source of truth.
• Responsive checks at 320 px, 768 px and 1280 px viewport widths, plus 200% browser zoom.

This assessment is internal. We have not yet commissioned an external accessibility audit; if you represent an accessibility consultancy and would like to talk to us, please get in touch.

10Feedback and contact

If you encounter an accessibility barrier on ivaestudios.com, or anywhere in our work, please tell us. We treat accessibility reports as a priority.

Our service-level commitment for accessibility reports is to acknowledge receipt within two (2) business days and to provide a substantive response (including, where possible, a fix or a workaround) within fourteen (14) calendar days. Where a fix requires more than fourteen days we will tell you so, explain why, and update you on progress until it is closed.

11Enforcement and approval

This statement is published voluntarily, in alignment with the spirit of the W3C Web Accessibility Initiative's model statement. We do not currently fall under a single specific national enforcement body: we are based in México, our clients are predominantly in the United States and Canada, and our visitors come from around the world. Where a regional regulator does have jurisdiction over you (for example, the U.S. Department of Justice in matters relating to the ADA, the European national authorities in matters relating to the Web Accessibility Directive, or the equivalent body in your country), this statement does not displace your rights to escalate.

This statement was prepared on 7 May 2026, last reviewed on 26 May 2026 by the IVAE Studios team, and approved by the studio's founder.