Accessibility is not a checklist. It is a product quality, engineering, and inclusion mindset.
I am a Software Engineer at HCLTech and a Digital Accessibility Consultant with 4+ years of experience helping teams create accessible, usable, and standards-aware digital products.
My work connects accessibility strategy with practical implementation: auditing interfaces, reproducing issues with assistive technology, writing actionable remediation guidance, and collaborating with designers and developers throughout the product lifecycle.
- π Web and mobile accessibility audits against WCAG 2.1 / 2.2, Section 508, and EN 301 549
- π§βπ¦― Manual testing with JAWS, NVDA, VoiceOver, TalkBack, keyboard navigation, and zoom/reflow checks
- π οΈ Accessible front-end reviews covering semantic HTML, ARIA, forms, focus management, and error handling
- π VPAT / ACR support, accessibility documentation, issue triage, and remediation roadmaps
- π Accessibility guidance and knowledge-sharing for design and engineering teams
| Capability | Focus |
|---|---|
| Manual testing | Keyboard-only navigation, screen readers, focus order, zoom, reflow, and color contrast |
| Assistive technology | JAWS, NVDA, VoiceOver, TalkBack, browser accessibility tools |
| Automated testing | axe-core, Lighthouse, Pa11y, WAVE, and CI quality checks |
| Engineering guidance | Semantic HTML, accessible CSS, ARIA patterns, forms, dialogs, tables, and error states |
| Deliverables | Audit reports, defect reproduction steps, remediation guidance, VPATs, and ACRs |
| Collaboration | Design reviews, component reviews, training, documentation, and accessibility strategy |
Each badge includes a readable label and the technology's own logo color, instead of displaying icons without context.
| Step | What it looks like |
|---|---|
| 1. Understand | Learn the product, users, journeys, constraints, and applicable accessibility requirements |
| 2. Evaluate | Combine automated checks, manual keyboard testing, assistive-technology testing, and code review |
| 3. Explain | Document the impact, affected users, reproduction steps, requirement mapping, and severity |
| 4. Enable | Give teams practical remediation guidance, examples, and reusable patterns |
| 5. Verify | Retest fixes, check regressions, and help establish repeatable accessibility checks |
- Start early: Include accessibility in discovery, design, component planning, and definition of done.
- Test with people and tools: Automated scans are useful, but they cannot replace manual and assistive-technology testing.
- Prefer native HTML: Semantic elements provide reliable structure, behavior, and communication to assistive technologies.
- Make defects actionable: A good finding explains the barrier, impact, location, reproduction steps, and practical fix.
- Design for flexibility: Support different input methods, text sizes, contrast needs, devices, and ways of perceiving information.
- Share ownership: Accessibility works best when product, design, engineering, QA, and content teams contribute together.
- π Building my personal portfolio at sharmavaibhav.site
- π Documenting accessibility audits, patterns, and remediation walkthroughs
- π§© Exploring accessible design systems and reusable component patterns
- π€ Open to accessibility consulting, audits, collaboration, and speaking opportunities
Building a more inclusive web, one experience at a time.


