Accessibility is integrated directly into design and development workflows at Xylora Studios, establishing WCAG 2.1 AA compliance as the working baseline for all web and digital builds. We address semantics, keyboard traversal, colour contrast, and assistive device compatibility during active production rather than retrofitting after launch.
Standards and baseline scope
Every bespoke website and digital interface produced by the Technology department targets WCAG 2.1 Level AA conformance. This covers colour contrast ratios (minimum 4.5:1 for normal body text, 3:1 for large text and distinct user interface components), focus states for keyboard navigation, logical heading hierarchies (H1 through H6), ARIA landmarks, form input labeling, and responsive reflow up to 400% zoom without loss of functionality.
Level AAA requirements or specialised criteria (such as British Sign Language video translations or cognitive-specific interfaces) are not part of our default scope. If your project demands Level AAA compliance or adherence to specific statutory frameworks, this must be stated during the initial scoping stage so the Technology team can specify the technical architecture accordingly within your bespoke quote.
Division of responsibilities
Accessibility is not isolated to code; it requires coordinated execution between our studio teams and your internal stakeholders:
* Creative department: Verifies typographic scale, visual hierarchy, touch targets (minimum 44x44 CSS pixels), colour contrast ratios across all colourways, and states for interactive elements (hover, focus, active). * Technology department: Builds clean semantic HTML5, manages dynamic DOM updates for screen readers, ensures full keyboard trap avoidance, writes accessible names for complex components, and conducts code-level audits. * Operations & Client Services: Schedules audits, logs technical remediation tasks, and manages handover documentation through the portal. * Client team: Supplies descriptive alternative text for brand imagery, provides transcriptions or captions for supplied audio and video assets, and preserves semantic document structures when updating dynamic CMS fields.
Sequence of events during production
Accessibility validation follows a strict sequence throughout the project lifecycle:
1. Design phase contrast checks: The Creative team runs automated and manual contrast calculations against the proposed brand palette and typography systems before layouts are approved. 2. Component build validation: As the Technology department builds modular components, each element is tested for keyboard operability (Tab, Shift+Tab, Enter, Space, and Escape controls) and exposed states via browser dev tools and screen readers. 3. Full-page screen reader and keyboard audit: Prior to staging sign-off, full pages undergo linear navigation testing using standard assistive tools (NVDA, VoiceOver) across desktop and mobile breakpoints. 4. Automated code sweep: Staging builds undergo automated linting and accessibility engine scans to identify missed attributes, orphaned labels, or heading gaps. 5. Handover and CMS training: At delivery, we outline how your editors must format headings, tables, and media within the CMS to prevent regression.
What the client must supply
To ensure your build meets compliance without delays, your team must deliver:
* Brand colour leeway: Permission to adjust secondary or accent hex codes if your existing brand guidelines do not meet mathematical contrast thresholds against specified backgrounds. * Media assets with transcripts: All pre-recorded video files must be accompanied by closed caption files (.vtt or .srt) or text transcripts, alongside descriptive copy for non-decorative imagery. * Third-party script documentation: Information on required legacy embeds, tracking pixels, or external widgets so our Technology team can evaluate whether they disrupt page semantics or introduce focus traps.
Failure cases and remediation
Three frequent issues cause accessibility failures during and after production:
* Inaccessible third-party widgets: Third-party booking engines, live chats, or cookie consent banners built by external vendors often fail accessibility tests. Where an external vendor's script breaks accessibility, the Technology team will attempt containment via an isolated iframe or accessible wrapper. If the vendor code cannot be adapted, the issue is logged as a third-party limitation, and alternate providers must be considered. * Client-introduced CMS regression: After launch, editors sometimes paste rich text containing inline font colours, broken heading levels, or unlabelled image uploads. Remediation for editorial regression falls outside the original project scope and requires support time logged via Ask Xylo. * Unapproved palette overrides: Demanding strict adherence to low-contrast brand hex codes without accepting studio adjustments will breach WCAG AA. In these cases, Operations will require a written variance sign-off acknowledging the non-compliant departure from studio standards.
Accessibility checklist
Before approving your technical handover, verify that your assets and content meet these checks:
* [ ] All non-decorative images have contextual, concise alternative text supplied. * [ ] Any supplied video features synchronized captions or an accessible transcript. * [ ] Brand palettes have been verified or adjusted to meet minimum 4.5:1 contrast ratios. * [ ] Interactive controls operate entirely using the keyboard without getting trapped. * [ ] Headings descend logically without skipping levels for purely visual sizing purposes. * [ ] Third-party tools and plugins have been vetted for screen reader operability.
For technical queries regarding your site audit or to request a bespoke remediation review, contact our Technology department via Ask Xylo chat on this portal during studio working hours (Monday to Thursday, 09:00-17:00 GMT).