Website Designer in Pune: Why Accessibility and Core Web Vitals Now Decide Who Gets Hired in 2026
A website designer in Pune who still pitches a project purely on visual polish — a beautiful mockup, a striking colour palette — is answering a question fewer clients are actually asking in 2026. Two technical concerns have moved from "nice to have" to genuinely business-critical: Core Web Vitals (Google's real-world performance metrics, now including a metric called INP that many Indian mobile-heavy sites are quietly failing) and accessibility (WCAG compliance, now backed by regulatory deadlines for some sectors and a rising global wave of litigation). Neither is exotic or optional anymore, and a designer who can't speak to both isn't fully equipped for a 2026 brief, however good their visual portfolio looks.
Core Web Vitals in 2026: the metric most Indian sites are quietly failing
Core Web Vitals are the specific, measurable performance signals Google uses as part of its ranking systems and, more practically, as a real proxy for whether an actual visitor has a good or frustrating experience on your site. There are three: Largest Contentful Paint (LCP, how fast the main content appears), Cumulative Layout Shift (CLS, whether the page jumps around as it loads), and — since March 2024, when it formally replaced First Input Delay (FID) — Interaction to Next Paint (INP), which measures how responsive the page feels when a visitor actually taps or clicks something.
INP is the one worth understanding specifically, because it's newer and less widely internalised than the older LCP/CLS metrics, and because it exposes a class of problem that used to hide behind FID's more forgiving measurement. A good INP score is 200 milliseconds or under; 200–500ms needs improvement; anything over 500ms is classified as poor. Independent tracking suggests only around a third of websites currently meet the "good" Core Web Vitals threshold across the board, and INP in particular tends to run meaningfully worse on mobile devices than the metric it replaced did — a real problem for a market like India, where a large share of traffic arrives on mid-range Android phones over patchy mobile networks, exactly the conditions where a heavy, JavaScript-dependent, poorly optimised page performs worst.
Why this is a design decision, not just a developer's problem
It's tempting to file Core Web Vitals under "backend performance" and assume it's someone else's job once the design is approved, but a meaningful share of INP and LCP problems originate in design decisions made before a single line of code is written:
- Heavy, uncompressed hero images and autoplay video are still the single most common LCP killer — a beautiful full-bleed hero image that hasn't been properly sized, compressed and served in a modern format (WebP/AVIF) delays the single metric Google weights most heavily, regardless of how good the developer implementing it is.
- Custom animations and interactive elements with unoptimised event handlers are a common INP culprit — a designer specifying an elaborate hover-and-scroll-triggered animation library without considering its runtime cost on a mid-range phone is designing directly into a poor INP score.
- Web fonts loaded without proper fallback strategy cause visible layout shift (hurting CLS) as text re-flows once the custom font finally loads — a decision made at the typography stage of a design, not the code stage.
- Dense, image-heavy page layouts with no defined image dimensions cause the page to visually jump as each image loads in, directly hurting CLS — again, a layout decision, not purely a technical one.
A designer who understands these tradeoffs designs with performance in mind from the first mockup — choosing a hero treatment that can be genuinely optimised, specifying font-loading behaviour, and being deliberate about where a rich animation is worth its performance cost and where it isn't — rather than handing a developer a beautiful design that's structurally difficult to make fast.
Accessibility: from ethical good practice to a regulatory and legal reality
Building an accessible website — one usable by people with visual, motor, auditory or cognitive disabilities, via screen readers, keyboard-only navigation, sufficient colour contrast, and properly structured content — has always been the right thing to do. What's changed by 2026 is that it's increasingly not optional, on two separate fronts.
The regulatory front in India
The Guidelines for Indian Government Websites (GIGW 3.0) mandate WCAG 2.1 Level AA compliance for public-sector platforms, and sector-specific regulators have begun extending similar requirements into the private sector — SEBI issued a circular in mid-2025 requiring regulated financial entities to complete third-party accessibility audits by a April 2026 deadline and remediate findings by mid-2026. TODO: confirm the current status and exact scope of this SEBI circular, and whether similar sector-specific mandates have since been extended to other regulators, before citing a specific compliance deadline to a client — regulatory rollouts of this kind are frequently extended, clarified or narrowed in scope after initial announcement, and treating an early news report as the final word is a real risk.
The litigation front, globally and as an early-warning signal for India
Website accessibility litigation — overwhelmingly under the Americans with Disabilities Act (ADA) in the US — has grown into a genuinely large, ongoing category of legal action, with recent annual filing counts in the thousands. India doesn't have an equivalent volume of website-specific accessibility litigation today, and it would be inaccurate to claim otherwise, but the Rights of Persons with Disabilities Act, 2016 does create a legal basis for accessibility obligations, and the pattern in most markets has been that litigation follows regulatory attention with a lag — which makes the US trend a reasonable early-warning signal for where India's own enforcement environment may be heading, not a claim that Indian litigation volumes already match it.
The part that matters regardless of regulation: real usability and real audience reach
Separate from both the regulatory and legal angles, an inaccessible website is one that genuinely doesn't work for a meaningful share of potential visitors and customers — the World Health Organization and multiple national surveys consistently estimate that a significant share of any population lives with some form of disability, whether visible or not, and a portion of that population interacts with the web using assistive technology daily. For an NGO in particular, where the audience often explicitly includes people the organisation serves, an inaccessible site can directly contradict the organisation's own mission — a disability-focused NGO whose own donation page can't be used by a screen-reader user is a genuinely uncomfortable contradiction worth actively avoiding.
What a genuinely accessible design process actually looks like
Accessibility retrofitted after launch is real, often substantial work — restructuring markup, redesigning colour combinations that fail contrast checks, rebuilding interactive components that were never built with keyboard navigation in mind. Building it in from the design stage is meaningfully cheaper and produces a better result. Concretely, that means:
- Colour contrast checked against WCAG AA thresholds at the palette stage, not discovered as a problem during a later audit — a brand palette that looks striking but fails contrast requirements for body text needs adjusting before it's locked in, not after.
- A logical heading hierarchy planned as part of the content structure, not applied cosmetically after the visual design is done — screen reader users frequently navigate by heading structure alone, and a page with headings chosen for visual size rather than genuine hierarchy actively breaks that navigation pattern.
- Every interactive element (buttons, form fields, custom dropdowns, image carousels) designed to be operable by keyboard alone, checked during design review, not discovered as a gap during a later accessibility audit.
- Meaningful alt text planned as part of the content brief, not left as an afterthought a developer fills in with the filename — this is a content and design decision as much as a technical one.
- Form validation and error messages designed to be clear and programmatically associated with their field, so a screen reader user gets the same "this field is required" feedback a sighted user sees visually.
How to actually measure both, rather than take a designer's word for it
You don't need to become a technical expert to hold a designer or agency accountable on either front — you need to know where to look.
For Core Web Vitals, Google's own PageSpeed Insights tool (free, at pagespeed.web.dev) gives you both a lab-simulated score and, for sites with enough traffic, real-world "field data" pulled from Chrome's Core Web Vitals reporting — the second is more reliable than the lab score alone, since it reflects actual visitors on actual devices rather than a single simulated test run. Google Search Console's Core Web Vitals report (under the Experience section) shows the same field data broken down by URL, flagging pages that fall into "poor" or "needs improvement" territory. Ask any designer or developer to walk you through this report for your own site, live, rather than accepting a verbal assurance that "it's fast."
For accessibility, browser-based tools like the axe DevTools extension (free) or Google Lighthouse's built-in accessibility audit (part of the same Chrome DevTools panel PageSpeed Insights draws from) catch a meaningful share of common issues automatically — missing alt text, insufficient colour contrast, missing form labels, improper heading structure. These automated tools are a genuinely useful first pass but do not catch everything — real keyboard-navigation testing and, ideally, testing with an actual screen reader (NVDA is free on Windows; VoiceOver is built into macOS and iOS) surface issues automated scanners miss entirely, particularly around logical reading order and whether custom interactive components behave sensibly for assistive technology.
Neither of these checks requires expensive tooling or specialist hiring to at least get a baseline reading — which makes "we haven't checked" a genuinely avoidable answer for any designer or agency working in 2026, not a reasonable limitation of a smaller budget project.
The cost of retrofitting versus building it in from the start
The economics here are stark enough to be worth stating plainly, even without precise universal figures (which don't exist, since the cost depends entirely on how deeply the problem is baked into the existing design and code):
| Issue | Cost if designed in from the start | Cost if retrofitted after launch |
|---|---|---|
| Colour palette failing contrast checks | Adjust palette during design review — near-zero added cost | Redesign brand colours across every page and marketing asset already built on them |
| Heading structure used only for visual sizing | Plan hierarchy during content architecture — no added cost | Restructure markup across every existing page, re-testing each for regressions |
| Unoptimised hero images hurting LCP | Choose an image strategy (sizing, format, compression) at design stage | Re-shoot or re-process every hero image, re-implement image handling across templates |
| Custom components with no keyboard support | Specify keyboard behaviour as part of the component brief | Rebuild the interactive component from scratch, often the most expensive category of retrofit |
| Heavy animation libraries hurting INP | Choose animation approach with performance budget in mind | Strip and rebuild interactions after the fact, often discovering the visual design depended on the very animation being removed |
The pattern in every row is the same: a decision made at the design stage costs little or nothing extra to get right, and the identical decision made after launch — once real content, real code and real users depend on the current version — costs meaningfully more to fix. This is the core argument for treating performance and accessibility as design inputs, not QA checkpoints discovered after the fact.
A practical checklist for evaluating a website designer in Pune on this
- Can they explain the difference between LCP, CLS and INP, and speak to which of their past projects has actually been measured against these thresholds — not just claim "we build fast sites"?
- Do they test designs on a genuinely representative mid-range Android device on a throttled connection, not just a high-end laptop on office wifi?
- Can they show a completed WCAG contrast check or accessibility audit from a past project, even an informal one?
- Is accessibility discussed at the design/wireframe stage, or only as an afterthought if a client specifically asks?
- Do they understand that a beautiful design that fails Core Web Vitals or basic accessibility checks is, functionally, an unfinished design — not a finished one with two extra boxes left unticked?
Why this pairs with SEO rather than competing with it
A useful way to think about the relationship between accessibility, performance and SEO: they're substantially the same underlying work, described to three different audiences. Semantic, well-structured HTML with a logical heading hierarchy is what a screen reader needs to navigate sensibly, and it's also exactly what Google's crawlers use to understand your content's structure. A fast-loading, well-optimised page is a better experience for a visitor on a mid-range phone, and it's also a directly measured Core Web Vitals ranking input. Descriptive alt text helps a screen reader user understand an image, and it's also one of the only ways Google's crawler has any idea what that image depicts. None of this is a coincidence — Google has been explicit for years that its ranking systems reward exactly the qualities (fast, accessible, well-structured, genuinely useful) that also make a site better for a human visitor with a disability. A designer optimising seriously for one of these three audiences (search engines, screen readers, mobile users on slow connections) is, in practice, mostly optimising for all three at once — which is the strongest practical argument for treating them as one connected discipline in a design brief, not three separate line items competing for budget.
How we approach design at Govindani Infotech
We've delivered 650+ websites out of Pune, and our design process treats performance and accessibility as design constraints from the wireframe stage, not a post-launch cleanup pass — checking colour palettes against contrast requirements before they're locked in, planning heading structure as part of content architecture, and testing builds against Core Web Vitals thresholds (including INP specifically) on realistic mid-range mobile conditions rather than only a development machine. This is the same discipline that underlies our broader website design and development work and the SEO foundations we build into every site, since a fast, accessible site and a well-ranking one are, in practice, the same underlying engineering discipline rather than two separate concerns competing for budget.
If you're briefing a redesign or a new build and want performance and accessibility treated as first-class requirements rather than an afterthought, we're happy to walk through what that actually looks like for your specific project. Read our broader guide on what to expect from a website designer in Pune, or if your current site is more a case of technical debt than a fresh design need, our website maintenance guide covers the ongoing side of keeping a site healthy. Reach us through our contact page to talk through your specific brief.
Sources: Google Search Central — Core Web Vitals, BKND Development — Core Web Vitals INP Optimization Guide 2026, Deque — India's Accessibility Laws, BeAccessible — 2026 Web Accessibility Statistics