Web Tech

Web Accessibility (WCAG 2.2) in Plain English

Web accessibility design and testing

Web accessibility used to be nice-to-have. It's increasingly a legal requirement, and it always was a moral one. It also correlates strongly with better UX, SEO, and site performance — the accessibility tax is lower than people fear.

Picking a Stack in 2026

The JavaScript ecosystem has settled into a set of pragmatic defaults. Next.js for full-stack apps. Astro for content sites. Plain React with Vite for dashboards and SPAs. SvelteKit as a compelling alternative for teams who want it.

The useful decision is not "what's the best framework" but "what fits this specific project and team". Frameworks are tools. Tools should be picked for jobs.

The Return of Server-Rendered HTML

The SPA-everything era has ended, at least for content-heavy sites. Server-rendered HTML with progressive enhancement is back in fashion for good reasons: faster first paint, better SEO, simpler mental model, smaller client bundles. Astro, Remix, Next.js App Router are all pushing this direction.

This doesn't mean SPAs are dead. Dashboards and deeply interactive apps are still best served by client-heavy React. But for marketing sites, blogs, and most e-commerce, HTML-first is winning again.

The Performance Floor Has Moved

What counts as an acceptable page load has shifted. A site that took four seconds to load in 2018 was fine. In 2026, that site is actively hurting conversion and SEO. The floor is now around 2.5 seconds for LCP, with top performers hitting sub-1.5 seconds.

Getting there isn't hard anymore. Modern hosting, modern image formats, sensible JS discipline. The bar is higher but the tools to clear it are better too.

Progressive Enhancement in 2026

Progressive enhancement, the idea that a site should work with minimal JavaScript and get better as more loads, fell out of fashion during the SPA-everything era. It's coming back, and for good reasons. Server-rendered HTML works on more devices, indexes better, and fails more gracefully when things go wrong.

Modern frameworks make this easier than it was a decade ago. Next.js App Router, Remix, Astro, SvelteKit — they all default to server-rendered HTML with progressive client hydration. You get the SPA-like experience when conditions allow, and a working site when they don't. That's a better architecture than SPA-first for almost every public-facing project. Related read: our post on Next.js vs React vs Astro covers the flip side of this.

How We Decide on Client Projects

Short decision tree. Marketing site or blog? Astro. E-commerce frontend? Next.js or headless Shopify. SaaS dashboard or app? Next.js or React + Vite. Internal tool? React + Vite. Content-heavy with some interactivity? Astro with React islands.

That's literally how we choose. It's not clever. It works.

Accessibility Is No Longer Optional

Legal requirements are catching up in multiple regions. The EU Accessibility Act is in force. India's RPwD Act applies to many categories of digital products. Lawsuits and regulatory action against non-compliant sites are increasing.

Also: accessible sites are better sites. They usually have better SEO, better mobile UX, and better conversion. The accessibility tax is lower than people fear, and the benefit extends beyond compliance.

The Build Tool Reality

Webpack, Vite, esbuild, Turbopack, rspack — the JavaScript build tool landscape keeps shifting. For new projects in 2026, Vite is the sane default. It's fast, well-maintained, and has excellent integration with every major framework. Webpack remains in legacy projects where migration isn't worth the disruption.

The thing to watch is how much time your build tool actually takes in your developer workflow. If you're waiting more than a few seconds for a dev reload, the tool is stealing productivity from every engineer on the team. The switching cost to a faster tool usually pays back within weeks.

The Web Platform in 2026

The web platform itself has continued evolving in ways that matter for developers. Modern CSS (container queries, cascade layers, :has() selector) makes it possible to build responsive designs without the JavaScript-heavy approaches of earlier eras. View Transitions API enables native-feeling page transitions. Web Components have quietly become more usable. These additions reduce the amount of framework magic needed for common patterns.

Frameworks themselves have matured and stabilised. Next.js, Remix, SvelteKit, Astro, and SolidStart all offer legitimate approaches to modern web development. The choice between them is more about fit than quality. React remains the default for apps, but the ecosystem around it has diversified in healthy ways.

Browser differences have mostly stabilised too. Chrome, Firefox, and Safari all support the same modern web APIs within reasonable tolerance. The IE era of painful cross-browser development is a distant memory. This is genuinely good for web developers — the platform is more capable and more consistent than it's ever been.

Web Development Myths Worth Ignoring

One: 'framework X is the best'. Context-dependent. Different frameworks win at different use cases. Picking on vibes rather than fit wastes months of team productivity.

Two: 'you need a JavaScript framework'. For many content sites, you really don't. Astro, Eleventy, or even hand-written HTML with sprinkles of JS produce better results for certain use cases than React ever will.

Three: 'optimising for performance hurts developer experience'. False. Modern tools (Vite, Turbopack, esbuild) give you fast dev experience AND fast production sites. That trade-off used to exist; it largely doesn't now.

A Framework Pick That Aged Well

In mid-2024 we built a content-heavy marketing site for a client who'd been burned by a previous React-heavy build that was slow and hard to maintain. The project was perfect for Astro, which had just hit version 3.

The bet was on a technology that was newer and less proven than the alternatives. We made it because Astro's island architecture was obviously the right shape for their problem: mostly static content with a few interactive islands. If we'd picked Next.js, it would have worked, but we'd have been fighting the tool for the whole project.

Two years later the site is still fast, still easy to maintain, and the client adds content themselves. Astro turned out to be the right call for that specific project. Not because Astro is the best framework in some absolute sense, but because it matched the problem. That framing — "what's the right tool for this problem" — is more useful than any framework ranking.

The Short Checklist

If you take nothing else from this post, take this checklist. It's what we'd hand to someone just starting out in this area. None of it is revolutionary. All of it is worth doing. The compound effect of consistently doing these things, even without any other clever moves, is meaningful over a year or two. We'd rather see a team do the checklist competently than chase the latest trend while skipping the fundamentals.

  1. Set performance budgets in your CI pipeline. Fail builds that exceed them.
  2. Use modern image formats. WebP at a minimum, AVIF if you can.
  3. Defer non-critical JavaScript. Every millisecond on main thread matters.
  4. Test with actual assistive technology. Automated tools catch 30%.
  5. Pick your JS framework deliberately, not fashionably.
  6. Monitor real-user metrics, not just lab ones.
  7. Run Lighthouse on production weekly. Small regressions compound.
  8. Review your top 5 landing pages monthly for performance and conversion.
  9. Keep dependencies updated. Long-unpatched dependencies accumulate risk.
  10. Test with real assistive technology at least quarterly.

We've watched enough teams succeed and fail at this over the years that the pattern's pretty clear. The winners aren't necessarily the smartest or the fastest. They're the most disciplined, the most honest about what they don't know, and the most willing to course-correct when the data tells them to. If you can do those three things consistently, you'll end up ahead of most of your competition. Not all of it — luck is real — but most of it. The final thing we'd say: don't try to do everything in this post at once. Pick the one or two items that clearly apply to your situation, commit to doing them properly, and leave the rest for later. Better to do a few things well than many things poorly.

One last thing. If you're wrestling with any of this right now and would appreciate a second pair of eyes, we're genuinely happy to help. Even a 30-minute conversation can save weeks of going down the wrong path, and we've built our business on relationships that started that way.

Frequently Asked Questions

Is web accessibility actually legally required in India?

Government websites have explicit GIGW requirements. Private websites are covered by the RPwD Act in specific contexts. The EU Accessibility Act applies if you serve EU users. Accessibility lawsuits are increasing globally. Even without specific legal requirements, making a site accessible reduces legal risk and opens your market to users you're currently excluding.

How much does it cost to make a site accessible?

Done from the start: 5-10% additional development cost. Retrofitted later: 30-50% of original build cost. The economics strongly favour getting accessibility right from the start. Most accessibility requirements are invisible to non-assistive-tech users, so you're not trading design for compliance.

Can automated accessibility tools replace manual testing?

No. Automated tools (axe, WAVE, Lighthouse) catch roughly 30-40% of accessibility issues. The rest require manual testing — keyboard-only navigation, screen reader testing, zoom testing. Use automated tools as a baseline, then do the manual work for real coverage.

Will making my site accessible hurt design or performance?

Almost never. Accessibility requirements are usually invisible (aria-labels, semantic HTML) or design-neutral (focus states, contrast ratios). They correlate strongly with better SEO, better mobile UX, and better performance. The accessibility tax is much smaller than people fear, and the benefits extend beyond compliance.

Need help with your project?

Orange Essence Technologies builds e-commerce, software, mobile apps and AI solutions for clients across India and around the world. If any of this is relevant to what you're working on, we'd love to chat.

Get in touch →