Accessibility Statement

Our Commitment

We believe the web should work for everyone. That's not just a tagline for us—it's literally what we do. As an accessibility company, we hold ourselves to the same standards we help our clients achieve. Everyone who visits our site, regardless of ability, should be able to navigate it, understand it, and use it without barriers.

We're committed to making sure our website meets the needs of people with visual, auditory, motor, and cognitive disabilities. This isn't a checkbox exercise for us. It's baked into how we design, build, and maintain everything we put online.

Conformance Standard

Our website strives to conform to WCAG 2.2 Level AA, the current version of the Web Content Accessibility Guidelines published by the World Wide Web Consortium (W3C). These guidelines are the internationally recognized benchmark for web accessibility.

We say "strives" because accessibility is an ongoing process, not a destination. We continuously audit and improve our site. Where we identify gaps, we work to fix them as quickly as possible.

What We've Done

Here's a non-exhaustive list of the accessibility work we've put into this site. We're being specific because vague statements like "we care about accessibility" don't help anyone:

Keyboard Navigation

• All interactive elements (links, buttons, form fields) are reachable and operable via keyboard alone
• We've implemented a "Skip to main content" link that becomes visible on focus, allowing keyboard users to bypass repetitive navigation
• Focus states are clearly visible with a consistent ring style across all interactive elements
• Tab order follows a logical reading sequence from top to bottom, left to right
• No keyboard traps exist—users can always tab out of any component

Visual Design

• Color contrast ratios meet WCAG AA requirements (4.5:1 for normal text, 3:1 for large text)
• Information is never conveyed by color alone—we use text labels, icons, and other visual cues alongside color
• Text can be resized up to 200% without loss of content or functionality
• We avoid text in images—all text is rendered as actual text that can be read by screen readers and resized
• Animations respect the prefers-reduced-motion media query where possible

Semantic Structure

• Proper heading hierarchy (h1 through h6) creates a logical document outline
• HTML5 landmark elements (nav, main, footer) help screen reader users navigate between sections
• Lists are marked up as actual lists, not just styled text
• Tables (where used) include proper headers and scope attributes

Images and Media

• All meaningful images have descriptive alt text that conveys the purpose or content of the image
• Decorative images are marked with aria-hidden="true" or empty alt attributes so screen readers skip them
• SVG icons include appropriate ARIA labels or are hidden from assistive technology when purely decorative

Interactive Components

• Buttons are actual <button> elements, not styled divs
• Links are actual <a> elements with meaningful link text (no "click here" nonsense)
• Mobile navigation menu is properly announced as a dialog with appropriate ARIA attributes
• External links include rel="noopener noreferrer" for security and indicate they open in new windows
• Form controls have associated labels

Focus Management

• Focus is managed appropriately when modals open (focus moves to the modal) and close (focus returns to the trigger element)
• The main content area has tabindex="-1" to receive focus when users activate the skip link
• Focus indicators are never removed, only enhanced

WCAG Success Criteria Addressed

For those who want specifics, here are some key WCAG 2.2 success criteria we've actively addressed:

• 1.1.1 Non-text Content: Alt text for images, ARIA labels for icons
• 1.3.1 Info and Relationships: Semantic HTML, proper heading structure
• 1.3.2 Meaningful Sequence: DOM order matches visual order
• 1.4.3 Contrast (Minimum): AA contrast ratios throughout
• 1.4.4 Resize Text: Content works at 200% zoom
• 2.1.1 Keyboard: Full keyboard operability
• 2.1.2 No Keyboard Trap: Users can always navigate away
• 2.4.1 Bypass Blocks: Skip to main content link
• 2.4.3 Focus Order: Logical tab sequence
• 2.4.4 Link Purpose: Descriptive link text
• 2.4.7 Focus Visible: Clear focus indicators
• 3.1.1 Language of Page: HTML lang attribute set
• 4.1.1 Parsing: Valid, well-formed HTML
• 4.1.2 Name, Role, Value: ARIA where needed

Testing Environment

We test our site across a variety of browsers and assistive technologies:

• Browsers: Chrome, Firefox, Safari, and Edge (latest two major versions)
• Screen Readers: VoiceOver (macOS/iOS), NVDA (Windows)
• Automated Tools: axe DevTools, Lighthouse, WAVE
• Manual Testing: Keyboard-only navigation, screen reader walkthroughs

Automated testing catches a lot, but not everything. We also do manual testing because some accessibility issues—like confusing tab order or unclear labels—only become apparent when you actually use the site the way a person with a disability would.

Technical Information

Our site is built with:

• React: Component-based architecture with accessibility hooks
• TypeScript: Type safety helps prevent accessibility bugs
• Tailwind CSS: Utility classes for consistent, accessible styling
• Framer Motion: Animations that respect user preferences

For the best experience, we recommend using an up-to-date browser with JavaScript enabled. The site is fully functional and accessible with JavaScript disabled, though some animations and interactive features may not work.

Legal Context

We align our accessibility efforts with the following standards and regulations:

• Americans with Disabilities Act (ADA): Requires accessible websites for places of public accommodation
• Section 508 of the Rehabilitation Act: Sets federal accessibility standards that often serve as benchmarks
• European Accessibility Act: EU directive requiring accessible digital services
• EN 301 549: European standard for ICT accessibility, harmonized with WCAG

While legal compliance is important, we don't do this because we have to. We do it because excluding people from using your website is fundamentally wrong, and frankly, bad for business.

Known Limitations

We try to be honest about where we're still working to improve:

• Some third-party embedded content (like Calendly booking widgets) may have accessibility limitations outside our direct control. We've chosen providers with the best accessibility track records we could find.
• Older blog posts may not meet all current standards. We're working through our content archive to bring everything up to date.
• PDF documents (if any) may not be fully accessible. We're working to remediate these or provide accessible alternatives.

Feedback and Contact

If you encounter any accessibility barriers on our site, we genuinely want to know about it. This isn't just corporate speak—we're an accessibility company, and if our own site isn't working for you, that's embarrassing and needs fixing.

Please reach out to us at pranav@woffy.com with:

• The page URL where you encountered the issue
• A description of the problem
• The assistive technology you were using (if applicable)
• Your browser and operating system

We aim to respond to accessibility feedback within 2 business days and to have a fix in place (or at least a workaround) within 10 business days for any significant issues.

Continuous Improvement

Accessibility isn't something you finish. It's something you maintain. We review our site regularly, especially when:

• We publish new content
• We add new features
• We update our design
• WCAG releases new guidelines
• Someone reports an issue

This statement itself will be updated whenever we make significant changes to our accessibility practices.