Home Services Book
§
§ · accessibility

Accessibility statement.

Where we stand on WCAG 2.1 Level AA, what we have shipped, where we still fall short, and how to tell us when something is broken for you.

Report an accessibility issue

last updated: 2 May 2026

This statement covers digitalheroes.co.in, our free tools at /tools/, and the work we ship for clients. We are Digital Heroes (DUNS No. 650878346), with HQs in New York and Delhi and satellite teams in London, Lucknow, and Sydney. Accessibility feedback: accessibility@digitalheroes.co.in.

Our commitment

An accessible web is the only kind of web worth shipping. People who use screen readers, keyboard-only navigation, voice control, magnification, or simply a wobbly trackpad on a moving train are the same people who buy from our clients, hire our team, and read our journal. If they cannot use the page, the page does not work, regardless of how it looks in a Figma frame.

We treat accessibility as part of the build, not a polish pass at the end. That means semantic HTML before ARIA, keyboard reachability before mouse hover states, and contrast checks before color decisions get locked in. The legal obligations under the ADA in the United States, the AODA in Ontario, and the European Accessibility Act of 2025 are the floor. The ceiling is the same rule we use for performance: if a real person on a real device cannot get the job done, we have not finished the work.

This statement is written in plain English, kept short on legalese, and updated whenever our practices or our known gaps change. If you find something on our site that breaks for you, the fastest way to fix it is to tell us. We will believe you, we will reproduce it, and we will fix it on a published timeline.

Conformance target

Our target standard is the Web Content Accessibility Guidelines (WCAG) 2.1 at Level AA, published by the W3C. We are also evaluating WCAG 2.2 (the September 2023 update that adds nine new success criteria around focus appearance, dragging movements, and cognitive load) and rolling its requirements into our default checklist as we revisit each template.

We claim partial conformance with WCAG 2.1 AA across the 580+ pages of digitalheroes.co.in. Honest disclosure matters here. We do not claim full AA conformance on every page because we cannot truthfully verify it on every page at this point, and overclaiming is itself a risk under FTC truth-in-advertising guidance and the basis of most ADA web complaints. Where we have audited a page (the home page, the services index, every flagship case study, every team profile, and the booking flow), we ship to AA. Where we have not yet audited (older tool pages, some legacy journal posts), we are working through them on a published cadence.

Measures we take

Accessibility shows up in two places in our build process. The development side is preventative; the QA side is verification.

Development side, by default on every page:

  • Semantic HTML first. <header>, <nav>, <main>, <article>, <section>, <footer> instead of generic divs.
  • ARIA attributes only where semantic HTML cannot do the job. We follow the first rule of ARIA: do not use ARIA if a native element with the same role exists.
  • Full keyboard navigation. Every interactive element is reachable by Tab in a logical order, every dropdown opens with Enter or Space, and every modal traps focus while open and restores it on close.
  • Visible focus indicators. We never set outline: none without replacing it. Our default focus ring uses the moss-500 token at a 2px offset for 4.5:1 contrast against the page background.
  • Color contrast. Body text targets a minimum 4.5:1 ratio, large text 3:1. We use the moss and amber tokens with verified ratios in both light and dark modes, except for the cases noted under known limitations.
  • Alt text on every meaningful image. Decorative images use alt="". Functional alt text describes what the image does, not a list of keywords (see the master prompt §33 retrofit pass linked under ongoing improvements).
  • Captions and transcripts on video. Every embedded case-study video on flagship pages ships with synchronized captions and a written transcript on the same page.
  • Reduced-motion support. All animations respect prefers-reduced-motion and degrade to static SVG fallbacks.
  • Form labels. Every input has an associated <label>, error messages use aria-describedby, and the booking form returns errors inline rather than as alert dialogs.

QA side, before each release:

  • Axe DevTools automated scan on every changed page.
  • Lighthouse accessibility audit in CI on the production build.
  • WAVE by WebAIM for visual evaluation of contrast and structural issues.
  • Manual screen-reader testing on flagship pages with NVDA on Windows and JAWS on Windows for at least one full task flow per release (booking a call, finding a case study, navigating to a service page).
  • Manual keyboard-only walkthrough on the same flagship pages, no mouse touched.

Automated tools catch roughly a third of accessibility issues. The other two-thirds need a human with a screen reader or a keyboard. We do both.

Known limitations

This is the part most accessibility statements skip. We will not. The following gaps are real, and we are tracking each of them with a remediation owner.

  • Animation iframes on tool pages. Some embedded interactive widgets and Three.js animations on our free tool pages do not yet expose a sufficient ARIA description for screen readers, and the amber accent on dark-mode hover states falls below 4.5:1 contrast in two of the eleven tools. Static fallbacks render correctly when prefers-reduced-motion is set.
  • Legacy tool pages. Tools shipped before our current accessibility checklist (roughly the first six tools, dated 2024) predate our current focus-indicator and keyboard-trap discipline. They are usable with assistive tech but have rough edges. Remediation is scheduled in the current quarter.
  • Image OCR text in older Gemini-generated case-study cards. A handful of older case-study cards use rendered text inside the image rather than HTML text, with the alt text describing the card visually. We are retrofitting these with proper functional alt text and, where the rendered text is more than incidental, replacing the image with HTML text on a background.
  • Third-party embeds. Some embedded content from third parties (a Vimeo player on one journal post, an X post embed on another) inherits accessibility characteristics from the third party that we do not fully control. Where we can host the same content first-party, we do.
  • Complex data tables. A small number of pricing comparison tables predate our current <th scope> and <caption> discipline. Audit and rewrite is in progress.

Browser and assistive-tech compatibility

The site has been tested with the following pairings:

  • Google Chrome (latest two stable versions) with NVDA on Windows 11.
  • Mozilla Firefox (latest two stable versions) with JAWS on Windows 11.
  • Safari on macOS (latest two stable versions) with VoiceOver.
  • Safari on iOS (latest two stable versions) with VoiceOver.
  • Microsoft Edge (latest two stable versions) with Narrator on Windows 11.

Not yet tested. We have not run end-to-end task flows with Dragon NaturallySpeaking voice control or with switch-input devices. If you use either of these and run into a barrier, please email us. Your report directly informs our next test pass.

How to give us feedback

The dedicated channel for accessibility feedback is accessibility@digitalheroes.co.in. The inbox is monitored by a named owner on our front-end team, not a generic support queue.

Our service-level commitment:

  • 5 business days for an acknowledgement that we have received your report and a named owner has been assigned.
  • 30 days for substantive remediation when the fix is technically feasible. If a fix is not feasible within 30 days (a third-party dependency, a structural rewrite), we will tell you why, what the realistic timeline is, and what workaround exists in the interim.

Alternative formats are available on request. If you cannot read this statement on the web, write to us and we will send the same content as a tagged PDF, plain-text email, large-print PDF, or any other format that works for you.

Formal approvals

We have not pursued formal WCAG-EM (Evaluation Methodology) certification or third-party VPAT (Voluntary Product Accessibility Template) attestation for digitalheroes.co.in. This is honest disclosure, not a hedge. Many agencies post a VPAT generated by a single contractor, and many "certifications" come from vendors who also sell remediation. We prefer to publish our actual practice, our actual gaps, and our actual cadence.

What we do every year: an internal annual audit using the tools listed above, a third-party scan via Axe Auditor on the full page index, and a manual screen-reader pass on every page that has shipped or materially changed in the last 12 months. We retain the full audit trail and will share it with any client who asks during a procurement review.

Ongoing improvements

What we are actively working on this quarter:

  • A color-contrast pass across all tool pages, replacing the two amber-on-dark hover states that fail 4.5:1.
  • Functional alt-text retrofit on every image across the site, per the master-prompt §33 standard (no keyword stuffing, describes what the image does).
  • WCAG 2.2 readiness review against the new 2.2 success criteria (focus appearance, dragging movements, target size minimum).
  • Screen-reader walkthrough recording for every flagship template, kept as an internal regression artifact.
  • Third-party-embed audit, with first-party replacements wherever a comparable host-it-yourself option exists.

For our clients

If you hire Digital Heroes for a build, accessibility is part of the deliverable, not a separate line item. We ship to WCAG 2.1 AA by default. We can target WCAG 2.2 AA or AAA on request, with a scope conversation up front about which AAA criteria are realistic for your project (a few are not technically feasible on a typical marketing site, and we will tell you which).

Every statement of work includes an explicit accessibility section: target conformance level, list of pages or templates in scope, audit tooling we will use, manual testing pairings, the named owner on our side, and the post-launch remediation window. Our UI/UX and web design work flows the same way: design files include focus states, contrast checks, and keyboard-flow notes before they leave Figma. Across 2,000 plus shipped builds in 55 plus countries, we have run formal WCAG audits on every flagship client engagement and the relevant evidence is available to clients on request.

Legal references

This statement is informational and is not legal advice. The laws and standards relevant to web accessibility in our primary markets:

If you believe we are not meeting any specific legal obligation in your jurisdiction, the fastest path to resolution is the feedback channel above.

Contact

Accessibility feedback, requests for alternative formats, and remediation requests: accessibility@digitalheroes.co.in. To help us reproduce and fix faster, please include the page URL, your browser and version, the assistive technology and version (if any), a short description of what you were trying to do and what happened instead, and your preferred response format.

For non-accessibility questions, see /contact/. For privacy questions, see /privacy/. For our terms of service, see /terms/. To learn who we are, see /who-we-are/. Postal: Digital Heroes, 1140 Broadway, Suite 704, New York, NY 10001, USA. India HQ: B-24, Connaught Place, New Delhi 110001, India.