Loading…
Loading…
Accessibility
Lady Holiday aims to be usable by everyone, including people who shop by keyboard, with a screen reader, at high magnification, or with motion turned off. This page records what has been done, what has not, and how to tell us when we have got it wrong.
Each row names the success criteria it addresses, so the claim can be checked rather than taken on trust.
WCAG success criteria: 2.1.1, 2.1.2, 2.4.3, 2.4.7
Every control is reachable and operable by keyboard. The bag drawer and the mobile menu trap focus while open, close on Escape, and return focus to the button that opened them. A visible focus indicator is applied globally with a two-tone ring so it stays visible on light and dark surfaces alike.
WCAG success criteria: 2.4.1
A “Skip to main content” link is the first focusable element on every page. Header, navigation, main and footer are real landmarks.
WCAG success criteria: 1.1.1
Every product photograph has alternative text that describes the piece and the view rather than repeating the file name. Decorative images — the homepage collage, card thumbnails already named by their link — carry an empty alt so they are skipped. Each product page also prints its photo descriptions as visible text, so the shop owner can review them.
WCAG success criteria: 1.3.1
One h1 per page, then a sequential outline with no skipped levels. Product and search result cards take their heading level from the page they sit on. Tabular data — the bag — is a real table with row and column headers.
WCAG success criteria: 2.2.2, 2.3.3
The testimonial carousel starts paused when the operating system requests reduced motion. When it does rotate, a Pause control is the first item in its tab order, it stops on hover and on keyboard focus, and taking manual control stops it for good. All transitions are disabled under prefers-reduced-motion.
WCAG success criteria: 3.3.1, 3.3.2, 3.3.3, 3.3.7, 3.3.8
Every field has a visible label, not a placeholder standing in for one. On submit, an error summary is announced and focused, listing each problem as a link to its field. Messages name the fix, not just the fault. Billing defaults to the delivery address already entered, and sign-in supports password managers and pasting with no puzzle or image challenge.
WCAG success criteria: 4.1.3
Adding to the bag, changing a quantity, re-sorting a grid and running a search all announce their outcome through a polite live region without moving focus.
WCAG success criteria: 1.4.1, 1.4.3, 1.4.11
Body text, controls and borders meet or exceed 4.5:1 against their background; the brand gold was darkened from #C5A059 to #8A6A21 for use on white. Stock state, order status and form errors all pair colour with an icon and with words. Category tiles sit on a gradient scrim so the label keeps contrast over any photograph.
WCAG success criteria: 1.4.4, 1.4.10, 2.5.8
The layout reflows to a single column with no horizontal scrolling at 320px and at 400% zoom. Pinch-zoom is never disabled. Interactive targets are at least 44 by 44 pixels, or smaller with compensating spacing.
These are open, not hidden. An accessibility statement without this section is marketing.
Alternative text on this demonstration build was derived from the live product feed, which contains no alt text at all. The wording is accurate to category, colour and view, but a human who has handled the piece should still review each one. On a production build this is a content workflow, not a one-off task.
This build demonstrates an accessible checkout flow but takes no payment. On Shopify, the final checkout step is served by Shopify and is only partly themeable: contrast and branding can be set from the admin, while the checkout’s own markup and scripts require Shopify Plus to modify.
The patterns here follow the ARIA Authoring Practices and have been checked by keyboard and against automated tooling. A full manual pass with NVDA on Windows and VoiceOver on macOS and iOS is part of the remediation engagement, not of this demonstration.
Review widgets, chat bubbles and pop-up apps can each introduce their own barriers and are frequently not fixable from the theme. Where that is the case the limitation belongs in this statement, named along with the vendor.
This site uses no accessibility overlay, toolbar or automatic remediation script. Overlays sit on top of the markup and cannot repair an unnamed link, a wrong heading level or a focus trap — the problems that actually stop people. They also tend to interfere with the assistive technology a visitor already uses and has configured to their liking.
Everything described above is fixed in the markup, the CSS and the JavaScript instead. That is slower and it is the only approach that holds up to testing.
If any part of this site gets in your way, we want to know — we treat it as a defect with a fix, not a feature request. Tell us the page, what you were trying to do, and what you use to browse, and we will reply within two business days.