How to Test an Indian Real Estate Website at 320-Pixel Mobile Width

Set the browser’s layout viewport to 320 CSS pixels, then check that ordinary vertically scrolling content reflows so important information and functions remain available without two-dimensional scrolling. Test real tasks such as finding a project, checking its details, opening documents, and submitting an enquiry—not only whether the homepage looks narrow.

320 pixels here means CSS pixels, not the physical pixel count of a phone screen. The Indian Government Website Guidelines (GIGW) include the WCAG 2.1 reflow criterion at this width. That criterion has an exception for content whose meaning or use requires a two-dimensional layout. GIGW is written for government websites and apps; this guide uses it as an India-specific reference for private property portals, without claiming that every private site is legally bound by it. See the GIGW guidelines and conformity matrix.

1. Choose pages and tasks that reflect how buyers use the site

Test a representative route through the site, including:

The homepage and its main navigation.
A property or project listing page, including search, filters, sorting, and pagination or load-more controls.
An individual project detail page, including status, approvals, amenities, location, and documents where provided.
An enquiry or contact flow, including validation and any confirmation state.

RERA portals are intended to help homebuyers make informed decisions and check project status and approvals. An IIHS review examined portals in 20 states and union territories and reported variation in information and standardisation. That review is evidence of variation in portal quality, not a claim that all sites fail mobile reflow. Read the IIHS publication.

2. Set and verify a 320 CSS-pixel viewport

Open the site in a desktop browser and enable its responsive or device viewport controls.
Set the layout viewport width to 320 CSS pixels. Set a practical height, such as 800 CSS pixels, so the page can be scrolled normally.
Keep browser zoom at 100% for the initial pass and record the browser’s displayed viewport dimensions.
Reload the page at that width. Some layouts only choose breakpoints during initial page load.

Do not confuse the viewport’s CSS width with a device’s physical pixels or device-pixel ratio. A high-density display may use more than one physical pixel for each CSS pixel. The reflow check is about the CSS layout width.

Browser automation example with Playwright

This runnable Node.js example opens a page at a 320 CSS-pixel viewport, saves a full-page screenshot, and reports whether the document is wider than its viewport. It is a useful triage check, not a complete accessibility audit.

npm install --save-dev playwright
npx playwright install chromium

// save as check-width.mjs
import { chromium } from 'playwright';

const url = process.argv[2];
if (!url) {
  throw new Error('Usage: node check-width.mjs https://example.com');
}

const browser = await chromium.launch({ headless: true });
const page = await browser.newPage({
  viewport: { width: 320, height: 800 },
  deviceScaleFactor: 1
});

try {
  await page.goto(url, { waitUntil: 'domcontentloaded', timeout: 45000 });
  await page.screenshot({ path: 'page-320.png', fullPage: true });
  const dimensions = await page.evaluate(() => ({
    viewportWidth: document.documentElement.clientWidth,
    documentWidth: document.documentElement.scrollWidth,
    viewportHeight: document.documentElement.clientHeight
  }));
  console.log(dimensions);
  if (dimensions.documentWidth > dimensions.viewportWidth) {
    console.log('Possible horizontal overflow: inspect the page and identify the element.');
  } else {
    console.log('No document-level horizontal overflow detected. Continue manual checks.');
  }
} finally {
  await browser.close();
}

Run it with node check-width.mjs https://example.com. The URL must point to a page you are permitted to inspect. A zero-overflow result does not prove that controls are operable, text is readable, or content is not clipped inside a nested container.

3. Inspect reflow from top to bottom

Scroll through the entire page at 320 CSS pixels. Look for these failures:

Horizontal page scrolling: the document or a major region extends off-screen.
Clipped or overlapping content: headings, prices, labels, cards, or controls are cut off or cover one another.
Hidden actions: a sticky header, cookie banner, floating chat control, or fixed footer blocks a button or field.
Unusable controls: filter chips, menu items, close buttons, and form controls are too cramped to use or cannot receive focus.
Missing information: responsive rules hide a price, project status, approval detail, document link, or other content needed for the task.
Text that does not adapt: long project names, addresses, or translated strings overflow instead of wrapping or resizing.

Some content genuinely needs two dimensions, such as a map or a data table. The reflow criterion makes an exception where the layout is essential to the meaning or use of that content. Check that the exception is limited to that region and that users can still reach the surrounding page content and controls.

4. Complete real-estate tasks at the narrow width

Keep the viewport at 320 pixels and perform each task with a mouse or touch emulation, then repeat key interactions with the keyboard:

Open and close the main navigation. Confirm menu items are visible, focusable, and not covered by another layer.
Find a location or project using the site’s search. Try a long location or project name if the data is available.
Apply and clear listing filters. Check that the selected state is visible and that controls do not push the page into sideways scrolling.
Open a project detail page. Locate project status, approvals, key facts, and document links where the site provides them.
Expand and collapse accordions. Verify that content is not cut off and the control indicates its state.
Open a document link and return to the project. Confirm the navigation remains usable at narrow width.
Submit the enquiry form with valid data and with a required field missing. Confirm errors are visible near the relevant fields and can be corrected.

This task list applies the reflow check to the information and activities a homebuyer may need. It is practical QA guidance, not a report of testing any particular portal.

5. Repeat for browsers, languages, and loading conditions

A page can behave differently across rendering engines, operating systems, fonts, and connection conditions. GIGW recommends evaluation across browsers and versions, operating systems, connection speeds, and screen resolutions. It also calls out checking Hindi and regional-language fonts for layout loss. Repeat the critical route in the environments your audience uses and in every language the site offers.

Check Hindi and regional-language pages using their actual Unicode text and fonts.
Look for words that do not wrap, glyphs that fall back to a different font, and buttons whose labels are truncated after translation.
Repeat important steps under a slower connection. Loading indicators, delayed images, or an error message should not permanently cover content or controls.
Check more than one browser engine where practical; a screenshot from one browser does not establish cross-browser behavior.

As current property-information context, the Press Information Bureau reported that TRAI launched a Digital Connectivity Rating platform on 25 September 2026. It provides a public interface to search rated properties, compare published ratings, and verify certificates. That platform is separate from the 320 CSS-pixel reflow criterion. See the PIB announcement.

6. Combine tool checks with human review

Use browser responsive controls and a screenshot or accessibility tool to find likely problems, then inspect the page and operate its controls yourself. GIGW calls for manual and tool-assisted evaluation of the 320-pixel criterion. Automated checks can identify some overflow or accessibility issues, but a person still needs to verify that project information and task flows remain usable.

For a quick browser-console overflow check, run:

const root = document.documentElement;
console.table({
  viewportWidth: root.clientWidth,
  documentWidth: root.scrollWidth,
  hasHorizontalOverflow: root.scrollWidth > root.clientWidth
});

If overflow exists, locate elements wider than the viewport:

[...document.querySelectorAll('body *')]
  .map(el => ({
    tag: el.tagName.toLowerCase(),
    selectorHint: el.id ? `#${el.id}` : el.className?.toString().split(' ')[0],
    left: Math.round(el.getBoundingClientRect().left),
    right: Math.round(el.getBoundingClientRect().right),
    width: Math.round(el.getBoundingClientRect().width)
  }))
  .filter(item => item.left < 0 || item.right > document.documentElement.clientWidth)
  .slice(0, 30);

This is diagnostic JavaScript for the browser console, not a pass/fail accessibility test. Fixed overlays, intentional carousels, and nested scrolling regions may need interpretation.

7. Record defects so they can be reproduced

For each issue, save the following:

Page URL and the task being performed.
Viewport width and height in CSS pixels.
Browser and version, operating system, and device emulation settings.
Site language and the exact text or data that triggers the problem.
Steps to reproduce, expected result, and observed result.
A screenshot showing the affected area and, for interactive defects, the preceding action.

For example: “At 320 CSS pixels in Chrome, Hindi project name wraps over the price in the listing card after applying the location filter. Expected: both remain readable and the details link is reachable.” A precise report helps a developer verify the fix at the same width and state.

8. Troubleshooting common failures

Symptom	Likely cause	What to check or fix
The page is wider than 320 pixels	A fixed-width element, unbroken string, wide image, or layout minimum width	Use the overflow locator above, then inspect the element’s width, wrapping rules, and parent constraints.
The screenshot looks like a desktop page shrunk down	The page may lack or misconfigure its viewport metadata, or the browser did not use the intended layout viewport	Verify the responsive browser controls and inspect the page’s viewport configuration. Reload after changing the viewport.
The document-width script reports no overflow, but content is cut off	Overflow may be clipped inside a nested container, or content may be hidden by CSS	Inspect the affected element and its ancestors; scroll the region and test whether the information remains reachable.
A sticky bar covers a form button	Fixed positioning or reserved space does not account for the narrow layout	Adjust the narrow-width layout, stacking, or scroll behavior, then retry the full flow.
Hindi or regional text overlaps	Translated labels are longer, glyph metrics differ, or the intended font is missing	Check font loading and wrapping; avoid fixed heights that assume one language’s line length.
A filter appears selected but results do not change	The interaction or state update may be broken rather than merely visually cramped	Test selection, clearing, keyboard operation, and the resulting list separately from the layout check.
The automated browser cannot load the page	Network delay, navigation timeout, authentication, or a browser-specific issue	Retry with a suitable timeout and the required authorized session; record the environment and distinguish a load failure from a reflow result.

9. Performance, reliability, and cost

A manual 320-pixel pass costs reviewer time but reveals whether the actual content and workflows make sense. A scripted viewport check is repeatable and useful in a page review or regression workflow, but its overflow measurement is only a signal. For reliable coverage, keep screenshots and defect records tied to the viewport, browser, language, and task state so another person can reproduce them.

For a small set of pages, browser developer tools and a local browser automation setup may be enough. For repeated captures across many URLs, consider the time to install and maintain browser infrastructure, handle dynamic pages, and organize evidence. Choose coverage and repeatability based on the number of pages and environments you need; the dossier establishes no benchmark or universal cost comparison.

10. Or skip the browser setup

ScreenshotNeo is a website screenshot API and MCP server for developers. Its one-call API can capture a page for visual review at a narrow viewport. See the ScreenshotNeo API documentation for request options and usage.

curl -G "https://api.screenshotneo.com/v1/shot" \
  -d access_key=YOUR_API_KEY \
  --data-urlencode url=https://example.com \
  -d viewport_width=320 \
  -d viewport_height=800 \
  -o page-320.webp

import requests

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

const q = new URLSearchParams({
  access_key: 'YOUR_API_KEY',
  url: 'https://example.com',
  viewport_width: '320',
  viewport_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 Bun.write('page-320.webp', new Uint8Array(await res.arrayBuffer()));

Use the returned image to inspect layout, then open the page at the same width to test interactions. ScreenshotNeo removes cookie and consent banners, newsletter popups, and chat widgets before capture; each cleanup step can be turned off. Bot checks, blank pages, timeouts, failed loads, and cache hits are not billed, and response headers identify the page verdict and billing status. Its MCP server provides take_screenshot, get_page_info, and capture_pdf for AI agents. One thousand screenshots per month are free with no card; paid plans start at $5 for 3,000. Every feature is on every plan. A screenshot does not replace keyboard, form, filter, or document-link testing.

Frequently asked questions

Does a 320-pixel check mean every Indian phone has a 320-pixel screen?

No. It is a CSS viewport width used for a specific reflow check, not a statement about the physical width of phones used in India.

Does passing this check prove the site is accessible?

No. It checks a specific reflow condition. Keyboard access, readable content, focus behavior, labels, contrast, and other accessibility requirements need their own evaluation.

Should every table or map fit into one narrow column?

No. Content that inherently needs two dimensions may use the criterion’s exception. Review the region and make sure the rest of the page remains usable.

Is the GIGW criterion automatically a legal requirement for a private property site?

This guide does not make that legal claim. GIGW provides India-specific guidance aimed at government websites and apps; private-site obligations depend on applicable rules and circumstances.

Sources

Government of India Website Guidelines and its conformity matrix for the 320 CSS-pixel reflow check and evaluation guidance.
Indian Institute for Human Settlements publication page for the review of RERA portals.
Press Information Bureau for the reported launch of TRAI’s Digital Connectivity Rating platform.