How to Test an Indian Government Website at Mobile Screen Sizes

To test an Indian government website at mobile screen sizes, set the browser’s layout viewport to 320 CSS pixels wide, then check that ordinary page content can be read and used without horizontal scrolling. Inspect important pages and interactions, repeat at other available viewport sizes or on real devices, and check readability with stylesheets unavailable. Treat this as one responsive-layout check—not proof of full GIGW or WCAG conformance.

The Guidelines for Indian Government Websites and Apps (GIGW 3.0) cover government websites and apps at central, state, district and local levels. Its responsive-layout checkpoint refers to a width equivalent to 320 CSS pixels. CSS pixels describe the browser’s layout viewport; they are not a handset’s physical screen pixels. The guidance calls for manual and accessibility-tool evaluation and recommends testing across devices. GIGW guidance and checkpoints

1. Set up a 320 CSS pixel viewport

Choose a representative set of pages, including the homepage, a content page, a search or service page, and any form or transaction flow. Include pages with tables, maps, embedded content, long labels, or other layouts that may behave differently on a narrow screen.

1. Open a page in a desktop browser and open its developer tools.
2. Enable the device or responsive viewport emulator.
3. Set the emulated viewport width to 320 CSS pixels. Choose a height that lets you inspect the page as you scroll; the responsive checkpoint is about width for vertical-scrolling content.
4. Reload the page at that size. A reload can reveal layout or content that depends on the initial viewport.
5. Check the rendered page and try its important controls. Record the page, viewport, browser, issue, and steps to reproduce.

Browser emulation is a practical way to set the viewport, not a browser or tool mandated by GIGW. Follow up with other available viewport sizes and actual target devices when possible; emulation does not reproduce every device, browser, input method, or network condition.

2. Check layout, content, and interactions

At 320 CSS pixels, scroll vertically through each selected page. The page should not require horizontal scrolling for ordinary content. Check:

• Text and headings: Look for clipped words, overlap, unreadably small text, or lines hidden behind fixed elements.
• Navigation: Make sure menus can be opened, closed, and operated, and that links remain visible and reachable.
• Forms and controls: Check that labels remain associated with their fields, fields fit the viewport, validation messages are visible, and buttons can be reached and activated.
• Images and media: Look for content extending beyond the viewport, missing alternatives, or controls that are too crowded to use.
• Tables and embedded content: Check whether important information remains available. Some content legitimately needs two-dimensional layout; review those exceptions for usability rather than treating every such region as an ordinary paragraph.
• Sticky headers, notices, and dialogs: Check that they do not cover page content or prevent access to controls.
• Language and real content: Test long names, dates, translated text, and realistic data. A layout that works with short placeholder copy may fail with actual content.

Horizontal scrolling can come from a child element rather than the document itself. In the browser console, this snippet lists elements whose right edge extends beyond the viewport. It is a diagnostic lead, not an automated pass/fail test:

const viewportWidth = document.documentElement.clientWidth;
[...document.querySelectorAll("body *")]
  .map((element) => ({
    element,
    rect: element.getBoundingClientRect(),
  }))
  .filter(({ rect }) => rect.right > viewportWidth + 1 || rect.left < -1)
  .map(({ element, rect }) => ({
    tag: element.tagName,
    id: element.id,
    className: typeof element.className === "string" ? element.className : "",
    left: Math.round(rect.left),
    right: Math.round(rect.right),
    width: Math.round(rect.width),
  }));

Inspect flagged elements in context. Intentional carousels or data regions may overflow their own scroll containers; a page-level overflow check alone cannot determine whether content is usable or whether an exception is appropriate.

3. Repeat at other sizes and on devices

A 320-pixel check is a useful narrow-width checkpoint, not a universal device matrix. Repeat on additional available viewport sizes, and use real devices that represent the browsers and platforms your users need to support. GIGW calls for testing on different devices; its app-specific guidance also discusses different device sizes and popular target-platform versions. Keep that app guidance distinct from the website’s 320 CSS pixel responsive-layout checkpoint.

For each run, note the viewport width in CSS pixels, browser and version, device or emulator, page, and whether the issue is reproducible. Include keyboard navigation and touch interaction where relevant. Do not infer which devices are most popular in India from the guideline: it does not prescribe a universal device list.

4. Check readability without stylesheets

GIGW’s related guidance asks evaluators to check that a website remains readable when stylesheets are turned off. Disable CSS through an available browser extension or testing setup, or inspect the page with stylesheets unavailable. Confirm that the content’s order and meaning remain understandable, and that links, headings, labels, and essential information can still be identified. This check complements responsive styling; it does not replace the 320-pixel viewport review.

5. Pair the visual check with accessibility evaluation

GIGW 3.0 incorporates WCAG 2.1 Level AA accessibility criteria. Use an accessibility tool to help find issues, then manually review important flows and applicable criteria. A tool can identify some problems, but a clean automated report or a successful 320-pixel check does not establish full conformance.

For a complete compliance effort, assess the site against GIGW 3.0 as a whole and consult the current STQC Website Quality Certification information. The mobile-width check by itself does not earn certification or establish a site’s current certification status. GIGW scope, objectives, and conformity guidance

6. Automate repeatable viewport screenshots

Automation can capture the same pages at a known viewport width for review or regression tracking. It does not decide whether a screenshot meets the checkpoint: inspect the output and test interactions separately. This runnable example uses Playwright’s Chromium browser. Install Playwright and its browser first with npm install --save-dev playwright and npx playwright install chromium.

// save as capture-mobile.mjs
import { chromium } from "playwright";

const target = process.argv[2];
if (!target) {
  throw new Error("Usage: node capture-mobile.mjs https://example.gov.in/");
}

const browser = await chromium.launch({ headless: true });
try {
  const page = await browser.newPage({
    viewport: { width: 320, height: 800 },
    deviceScaleFactor: 1,
  });
  const response = await page.goto(target, {
    waitUntil: "networkidle",
    timeout: 60_000,
  });
  console.log({
    url: page.url(),
    status: response?.status() ?? null,
    viewportWidth: await page.evaluate(() => document.documentElement.clientWidth),
    documentWidth: await page.evaluate(() => document.documentElement.scrollWidth),
  });
  await page.screenshot({ path: "mobile-320.png", fullPage: true });
} finally {
  await browser.close();
}

Run it with node capture-mobile.mjs https://example.gov.in/. The width comparison is a warning signal: document overflow can have intentional or exceptional causes, and no overflow reading proves that text or controls are understandable. Review the screenshot and manually exercise the page. For a flow that never reaches network idle, adjust the wait strategy to the page’s behavior and use an explicit readiness condition rather than assuming every site has the same loading pattern.

Or skip the browser setup

For a screenshot to review at the target width, ScreenshotNeo accepts a URL and viewport settings in one API request. Its documentation describes the API and options. A screenshot helps inspect appearance; use a browser and manual checks for interaction and conformance evaluation.

curl -G "https://api.screenshotneo.com/v1/shot" \
  -d access_key=YOUR_API_KEY \
  --data-urlencode url=https://example.gov.in/ \
  -d width=320 \
  -d height=800 \
  -o mobile-320.webp

import requests

r = requests.get(
    "https://api.screenshotneo.com/v1/shot",
    params={
        "access_key": "YOUR_API_KEY",
        "url": "https://example.gov.in/",
        "width": 320,
        "height": 800,
    },
    timeout=90,
)
r.raise_for_status()
open("mobile-320.webp", "wb").write(r.content)

const q = new URLSearchParams({
  access_key: 'YOUR_API_KEY',
  url: 'https://example.gov.in/',
  width: '320',
  height: '800',
});
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`Screenshot request failed: ${res.status}`);
await import('node:fs/promises').then(({ writeFile }) =>
  writeFile('mobile-320.webp', Buffer.from(await res.arrayBuffer()))
);

ScreenshotNeo removes cookie banners, newsletter popups, and chat widgets before capture; bot checks, blank pages, and failed loads are never billed. Its MCP server lets AI agents take screenshots. The free plan includes 1,000 screenshots per month with no card, and paid plans start at $5 for 3,000. Learn about ScreenshotNeo or sign up for 1,000 free screenshots a month, with no card.

Common problems and fixes

Symptom	Likely cause	What to check or change
Horizontal scrolling appears at 320px	A fixed-width child, unwrapped text, oversized media, or a layout rule forces content wider than the viewport.	Use the overflow diagnostic to locate candidates. Check widths, wrapping, grid or flex constraints, and media sizing; retest the page after changes.
The viewport says 320px but the site looks like desktop	The page may be missing or misconfiguring the viewport meta tag, or the emulator may not be in device mode.	Check the document’s viewport metadata and verify the browser’s emulated layout viewport width.
Some content is missing in the screenshot	It may load after a delay, appear after scrolling, or require interaction.	Wait for a meaningful page element, scroll to trigger lazy loading, or exercise the interaction in a browser. A single initial screenshot cannot reveal every state.
Automated navigation times out	The site may keep connections open or never reach the chosen network-idle condition.	Use a different readiness condition, such as waiting for a relevant selector, and set a suitable timeout. Confirm manually that the page finished rendering.
Automated output differs from a real handset	Browser emulation does not reproduce all device hardware, browser behavior, input methods, or network conditions.	Compare on available real devices and record the environment for each finding.
CSS-off rendering appears disorganized	The content order or essential distinctions may depend on presentation styles.	Check semantic structure and reading order as well as visual styling; verify essential content remains understandable without stylesheets.

Performance, reliability, and cost of the test

• Keep the test set focused: Start with representative templates and critical service flows, then expand when they expose different layouts or failures.
• Separate capture from judgment: Automated screenshots make repeat captures convenient, but a human still needs to inspect content and interactions.
• Make runs reproducible: Record page, viewport, browser, wait condition, and relevant state. Public sites can change, so compare captures only when their context is clear.
• Account for dynamic content: Timers, rotating banners, personalization, network delays, and lazy loading can make captures differ. Wait for meaningful readiness and note any state that affects the result.
• Budget for coverage rather than pixels alone: One viewport and one page are inexpensive to inspect but provide limited evidence. Add device, accessibility, and full-guideline evaluation appropriate to the compliance task.

FAQ

Does passing at 320 CSS pixels mean the site is GIGW compliant?

No. It addresses one responsive-layout checkpoint. GIGW 3.0 includes many other website and accessibility requirements.

Does GIGW require testing on a specific phone or browser?

The cited guidance recommends testing on different devices but does not prescribe a universal device or browser matrix.

Can a screenshot prove that a form works at mobile size?

No. A screenshot records appearance at capture time. Submit the form and check its controls, validation, keyboard access, and resulting state in a browser.

Is 320 the phone’s hardware resolution?

No. It is the equivalent CSS viewport width used for the responsive-layout check, not a physical pixel measurement.

References

• GIGW 3.0 official guidelines
• GIGW checkpoint guidance
• GIGW scope and conformity guidance
• STQC Website Quality Certification information