Smeron
All Work
Web portal

GTU Website Redesign

  • Accessibility
  • Performance
GTU Website Redesign — Web portal

A responsive web portal for GTU built in Next.js, with accessible UI components and heavy performance work.

Who it was built for

The business, and what they came with.

Built for

GTU

A public technical university. Its website is the front door for applicants, enrolled students and affiliated colleges, and for most of them it is the only contact they will have.

The brief

Tens of thousands of students read this portal on mid-range phones and patchy connections, often to find one notice under deadline. It had to be fast and legible in those conditions, not on a designer's laptop.

What we delivered

What GTU has now that they did not have before.

  • Components that meet accessibility requirements

    Keyboard operation, contrast and semantic structure built into the component set, so compliance holds as departments add pages.

  • Performance treated as the feature

    Heavy optimisation work aimed at the low end of the device range, because that is the device most of this audience is holding.

  • A design system, not a redesign

    Type scale, colour roles and spacing published as tokens, so the next person to touch the site inherits decisions instead of guessing.

What it changes for the university

Why each piece of the build pays for itself.

  • Fewer questions reach the desk

    Every student who finds the notice themselves is one who does not call, email or queue for it.

  • It works on the phone people own

    A portal that is only usable on fast connections quietly excludes the students who most depend on it.

  • The next page looks right by default

    Tokens and accessible components mean consistency does not depend on whoever is briefed next.

The business analysis

Market, model and architecture. Every figure is either cited or labelled as a model.

A public university's website has no revenue line, which makes it easy to under-invest in and expensive to get wrong. The analysis worth doing here is not commercial but operational: the portal is the front door for applicants, enrolled students and affiliated colleges, and every student who cannot find a notice on it becomes a phone call, an email or a person in a queue. That is the cost this project was against, and it is real money even though nobody invoices it.

Home pages with detectable WCAG failures
94.8%
Across the top one million home pages, averaging 51 distinct errors each. Accessibility is the default state of the web, and the default is failure.

Source · The WebAIM Million, 2025 report

The conformance level GIGW sets
WCAG 2.0 AA
India's guidelines for government websites and apps require this level, so accessibility here is an obligation rather than a preference.

Source · Guidelines for Indian Government Websites and apps (GIGW)

Global web traffic from mobile
60.5%
July 2025. For this audience the share is higher still, and the devices are further down the performance range.

Source · StatCounter data, via Visual Capitalist

The LCP threshold that counts as good
2.5s
Google's own bar. It is measured on the device the reader is holding, which is the entire point of the performance work here.

Source · Largest Contentful Paint (LCP), web.dev

Accessibility here is compliance, not conscience

Most organisations treat accessibility as an ethical preference they will get to. For an Indian public institution it is codified: the Guidelines for Indian Government Websites and apps require conformance with W3C's Web Content Accessibility Guidelines 2.0 at level AA 1, framed around what the guidelines themselves call the trilogy of usability, user-centricity and universal accessibility 2.

The WebAIM Million shows how rarely that is achieved anywhere. Across the top one million home pages, 94.8% had detectable WCAG 2 A or AA failures, averaging 51 distinct errors per page 3.

Detectable accessibility errors per home page

WebAIM's automated analysis of the top one million home pages, year on year. Automated tools catch only a portion of real failures, so these are floors rather than totals.

2024 analysis
56.8
2025 analysis
51

A 10.3% improvement, and still 51 errors on a median home page.

Source · The WebAIM Million, 2025 report

The performance work is an inclusion argument

Globally, mobile accounted for 60.5% of web traffic in July 2025 4. For this audience the figure is higher and the hardware is worse: tens of thousands of students reading a portal on mid-range phones and patchy connections, often to find one notice under a deadline. Google's threshold for a good Largest Contentful Paint is 2.5 seconds, measured on the reader's own device 5 — which is the only place the measurement means anything.

Optimising forWhat it producesWho it serves
A designer's laptop on office wifiA portal that demos beautifullyNobody in the audience
A mid-range phone on mobile dataSlower to build, and usable under deadlineThe students who most depend on the portal
A screen reader and keyboardStructural work with no visual payoffA minority whose alternative is the front desk

Where the value of this rebuild sits for the institution

Our apportionment of the three delivered capabilities by their contribution to the university's actual problem, which is service load rather than revenue.

Findability under deadline40%
Every student who locates a notice themselves is one who does not contact the university about it.
Working on the device people own30%
A portal usable only on fast connections quietly excludes the students who most depend on it.
Durable consistency via tokens30%
The next page looks right, and stays compliant, without anyone being briefed.

Model · Our weighting of the three delivered capabilities against the institution's service objectives.

One student, one notice, under deadline

The whole portal can be judged against a single task, and that task is not exploratory browsing. It is a student with a deadline looking for one document, on a phone, possibly on a train.

The task the portal is actually used for

Five steps, and the offshoots are the failure states that turn a web visit into a phone call.

  1. Arrives from search, on a phone

    Not from the home page. Any assumption about navigation order that depends on entering at the top is wrong for most visits.

  2. First contentful paint on a slow connection

    The performance work is aimed at the low end of the device range, because that is the device most of this audience is holding.

    • ↳ Slow network → content before decoration, or the visit is abandoned
  3. Is the notice findable?decision

    One document, under a deadline. This is the moment the portal either works or generates a support contact.

    • ↳ Not found → phone call, email, or a queue at the desk
    • ↳ Screen reader user → semantic structure decides whether it is reachable at all
  4. Read or downloaded

    Legible at the default text size, operable by keyboard, and with contrast that survives direct sunlight.

  5. No contact generated

    The successful outcome is silence. It is also the reason this kind of work is chronically under-valued: nothing measurable happens.

The design system is the governance mechanism

Publishing type scale, colour roles and spacing as tokens looks like a documentation exercise. In an institution it is the only way a standard survives staff turnover. The tokens on this page are the deliverable: a department that inherits them inherits the decisions, including the contrast ratios that make the palette compliant.

How the standard is enforced structurally

Each layer removes a category of decision from whoever builds the next page. That is what makes consistency durable rather than supervised.

  1. Tokens

    Type scale, colour roles and spacing as named values. A page author picks a role, not a hex code, so contrast cannot be broken by accident.

    • Heritage Blue
    • Trust Blue
    • Type scale
    • Spacing scale
  2. Accessible components

    Keyboard operation, focus handling and semantic structure built in, so conformance is inherited rather than reviewed.

    • Semantic markup
    • Keyboard operation
    • Contrast compliance
  3. Page composition

    Departments assemble pages from the component set. The constraint is the feature: fewer decisions, fewer regressions.

    • Next.js
    • TypeScript
    • Tailwind CSS
  4. Delivery

    Performance work aimed at the low end of the device range, because that is where this audience is.

    • Image optimisation
    • Framer Motion, used sparingly

What we would watch

RiskWhy it bitesEarly indicator
Departmental driftMany teams publish into one portal. Tokens hold the standard only while people use the component set rather than working around itPages appearing with inline styles or colours outside the token set
Content weight creeping backPerformance gains on a portal are usually lost to added content, not to code — a carousel here, a PDF thereLCP regressions traceable to content additions rather than to releases
Compliance without usabilityPassing an automated WCAG check is not the same as being usable by a screen reader. Automated tools catch only part of the problemZero detected errors alongside continued support contacts from assistive-technology users

References

  1. 1.Guidelines for Indian Government Websites and apps (GIGW) · Government of India
  2. 2.GIGW — scope and objective · Government of India
  3. 3.The WebAIM Million — annual accessibility analysis of the top 1,000,000 home pages · WebAIM, Utah State University
  4. 4.Desktop vs mobile global web traffic (StatCounter data) · Visual Capitalist
  5. 5.Largest Contentful Paint (LCP) · web.dev, Google

Reference

For the technical reader. Everyone else has what they need above.

Recommended case studies

The closest work to GTU Website Redesign, scored for relevance rather than picked by position.

Want the version of this built for your business?

Fifteen minutes with the people who shipped it. No deck, no account manager.