Apply for AI Grants India

What accessibility-focused employers look for

A strong frontend developer portfolio for accessibility roles proves two things at once: you can build production-quality interfaces, and you understand how disabled people experience them. A list of tools or a generic statement about inclusion is not enough. Hiring teams want evidence of decisions, testing, trade-offs, and outcomes.

This matters across roles such as accessible frontend engineer, design systems engineer, accessibility specialist, UI engineer, and developer advocate. In India, where teams often build products for multilingual, mobile-first audiences, accessibility also intersects with low bandwidth, small screens, varied devices, and public-service use cases.

Your portfolio should answer four questions quickly:

• What can you build?
• Which accessibility problems have you solved?
• How did you validate the result?
• What would you improve next?

Choose projects that demonstrate judgement

Three well-documented projects are usually more persuasive than ten shallow demos. Select work that shows different accessibility challenges and technologies. For example:

• A form-heavy workflow with clear labels, validation, error recovery, and keyboard support.
• A responsive dashboard tested at zoom levels and on narrow screens.
• A component library with accessible buttons, dialogs, tabs, menus, tables, and status messages.
• A multilingual or low-bandwidth interface where readable typography and resilient layouts matter.
• An open-source contribution that fixes a real accessibility issue.

If you are early in your career, build a focused project rather than a decorative landing page. A useful case study could redesign a college admissions form, a municipal service flow, or a small-business checkout journey. You can also pair accessibility work with broader open-source projects for student developers, provided your contribution is clearly described and independently verifiable.

Structure every case study around evidence

Do not present a project as a screenshot gallery. Use a repeatable case-study format:

1. Context: Explain the product, users, constraints, and your responsibilities.
2. Problem: Identify the accessibility barriers. Include the affected interaction, not just a general claim.
3. Approach: Describe your semantic HTML, component, CSS, and interaction decisions.
4. Testing: State what you tested manually and automatically, with browsers, devices, and assistive technologies where relevant.
5. Outcome: Report concrete changes, such as fewer keyboard traps, improved form completion, resolved axe findings, or better focus visibility.
6. Reflection: Note limitations and the next improvement you would make.

A concise before-and-after comparison is effective. For example: “The original modal trapped focus inconsistently and closed when users activated an unrelated control. I replaced it with a native dialog pattern, added predictable focus return, and tested it with keyboard navigation and a screen reader.” This demonstrates implementation skill and reasoning without overstating compliance.

Show practical WCAG knowledge

You do not need to reproduce the entire Web Content Accessibility Guidelines specification. Demonstrate that you can apply its principles in code. Mention relevant success criteria only when they clarify a decision, such as keyboard operation, visible focus, meaningful headings, error identification, or sufficient contrast.

Your portfolio projects should visibly include:

• Semantic landmarks and a logical heading hierarchy.
• Labels, instructions, and useful error messages for forms.
• Full keyboard operation without focus traps.
• A visible, high-contrast focus indicator.
• Correct names, roles, states, and values for custom controls.
• Responsive layouts that work with zoom and text resizing.
• Captions or transcripts for meaningful video and audio.
• Reduced-motion support where animation could create discomfort.
• Language metadata and readable, plain interface copy.

Use ARIA carefully. A case study that explains why native HTML was preferable to a custom widget often signals stronger judgement than one that lists many ARIA attributes.

Make testing reproducible

Accessibility testing is more credible when another developer can repeat it. Add a short test matrix to each project, covering browser, viewport, keyboard path, screen reader, and automated checks. Useful tools include axe-core, Lighthouse, WAVE, browser accessibility trees, and framework-specific testing libraries. Automated tools catch only a portion of accessibility issues, so explain what you checked manually.

A practical workflow might include:

• Run linting and automated accessibility checks in development and CI.
• Navigate the complete primary flow with only a keyboard.
• Test headings, landmarks, forms, dialogs, tables, and status updates with a screen reader.
• Check zoom, reflow, contrast, focus visibility, and reduced motion.
• Ask disabled users or accessibility practitioners for feedback when the project allows it.
• Record known limitations instead of claiming that a tool proves full compliance.

Include test notes in the repository. A clear README, issue log, and small set of regression tests make the project more useful to hiring managers than a polished live demo alone. If you use AI coding tools, disclose where they helped and how you reviewed the output; accessibility bugs introduced by generated code still remain your responsibility. Guidance on building personalised portfolio websites with AI agents can help with presentation, but do not let automation replace your own testing.

Make the portfolio itself accessible

Your portfolio is the first accessibility audit you are likely to receive. Build it as a production-quality example:

• Use a simple, semantic document structure with a skip link.
• Keep navigation predictable and keyboard-operable.
• Provide descriptive link text and useful image alternatives.
• Preserve visible focus and support zoom, reflow, and text resizing.
• Avoid autoplay, flashing content, pointer-only interactions, and excessive motion.
• Ensure buttons, links, forms, and code samples have accessible names.
• Publish a contact method that does not depend on a visual puzzle or inaccessible form.

Test the site on a phone and desktop, at 200% zoom, with keyboard-only navigation, and with at least one screen reader. Add an accessibility statement that is specific about what you tested, known issues, and how visitors can report a barrier. A static site is fine; a complex visual effect is not a substitute for accessible engineering.

Present skills without keyword stuffing

Organise your skills by capability rather than listing every tool you have opened. A useful structure is:

• Foundations: HTML, CSS, JavaScript, responsive design, performance.
• Frameworks: React, Vue, Angular, or another framework, with accessible component patterns you have implemented.
• Testing: axe-core, Lighthouse, keyboard testing, screen readers, browser devtools, unit and end-to-end tests.
• Delivery: Git, code review, CI checks, documentation, issue triage, and collaboration with designers.
• Standards: WCAG principles, inclusive design, and platform accessibility APIs.

Link each important skill to evidence. For instance, “accessible React dialogs” should point to a case study or repository showing focus management, escape handling, focus return, and testing. Contributions to Indian open-source AI developer projects can also demonstrate collaboration, but explain the accessibility-specific work rather than relying on the project’s reputation.

Write for recruiters and engineers

Recruiters need a fast summary; engineers need depth. Put a two- or three-line positioning statement near the top, followed by featured projects, skills, and contact details. Each project card should show the problem, your contribution, technology, accessibility focus, and links to the live build and repository.

Avoid vague claims such as “passionate about inclusion.” Replace them with measurable or inspectable evidence: “Reworked a six-step form for keyboard and screen-reader use,” “added automated checks to CI,” or “documented unresolved issues after testing with NVDA and VoiceOver.” Do not publish private client code or unverified testimonials. Redact sensitive information and state when a case study is based on a personal reconstruction.

A practical publishing checklist

Before sharing your portfolio, confirm that:

• Your strongest accessibility project is visible without hunting through menus.
• Every case study explains context, decisions, testing, and limitations.
• Live demos and repositories work on mobile and desktop.
• The portfolio passes keyboard, zoom, reflow, focus, and screen-reader checks.
• Your resume, email, and LinkedIn or GitHub links are accessible.
• Project dates, role, team size, and contribution are accurate.
• You have a clear contact route and a short accessibility statement.

Keep the portfolio current by replacing weak projects, documenting new fixes, and updating test results—not by adding more badges. A focused, honest portfolio gives accessibility-focused employers confidence that you can carry inclusive frontend practices from design review through shipped code.