How to Test an Indian Bank Website at Mobile Viewport Sizes

To test an Indian bank website at mobile viewport sizes, define the pages and journeys to cover, test them at documented CSS viewport dimensions, and record layout, interaction, accessibility, browser, device, and network results. Include a narrow-width check at 320 CSS pixels, then validate high-risk journeys on supported physical devices. A single emulated viewport cannot prove that a site works on every phone.

Banking-sector accessibility guidance calls for accessible websites and apps and references IS 17802 and WCAG 2.1. It names practical website features including skip-to-main-content access, text-size and spacing options, structured headings, page titles, and alternative text. GIGW provides a useful specific 320 CSS-pixel responsive check, but it is government website and app guidance, not by itself a bank-specific regulation. See the banking-sector accessibility guidance and GIGW criteria.

1. Define the test coverage

Start with the bank’s own supported-browser and device information, customer context, and journey risk. The available guidance does not define a universal device matrix for Indian banks, so document why you chose each combination rather than presenting an arbitrary phone list as official.

Choose pages that exercise different layouts and controls. Depending on authorization and the test environment, these may include:

Public contact, help, branch, service, or product information pages.
Sign-in and recovery journeys using approved test accounts.
Account summaries, tables, or disclosures using non-production data where possible.
High-risk transaction journeys only where access, credentials, and environment are explicitly authorized.
Dialogs, menus, forms, validation errors, confirmation messages, and other important states.

For every run, record the page or journey, viewport width and height in CSS pixels, browser and version, operating system, physical device or emulation, orientation, zoom and text settings, accessibility settings, network condition, date, and observed result. CSS pixels are the browser layout dimensions; record them separately from a phone’s physical screen resolution.

2. Run the responsive checks

Open the page at the intended viewport size and note whether the run uses browser emulation or a physical device.
Check that the main content is present and follows a sensible reading order. Confirm that navigation is reachable and can be opened and closed.
Inspect forms: labels, inputs, validation messages, buttons, and submit controls should fit and remain operable. Try expected and invalid inputs in the approved environment.
Inspect dialogs, menus, banners, and disclosures. Confirm they fit within the viewport and their controls remain reachable, including when the on-screen keyboard is open.
Look for clipped text, overlap, hidden controls, unexpectedly missing content, and avoidable horizontal scrolling.
Record defects with a screenshot and steps to reproduce, then repeat after a fix using the same conditions.

Include 320 CSS pixels as a narrow-width check. GIGW’s WCAG-derived criterion describes presenting content without horizontal scrolling at a width equivalent to 320 CSS pixels for the cited case. Its guidance also mentions a 256 CSS-pixel height case for text intended to scroll horizontally. Keep the scope attached to the source: this is a concrete reference from GIGW, not a claim that this viewport alone establishes compliance for a bank. See GIGW’s guidelines.

3. Check accessibility at every tested width

Responsive layout changes can make an otherwise available control hard to use. Repeat accessibility checks at the same widths and in the same important journeys.

Navigate by keyboard. Check the focus order, visible focus, and whether menus, dialogs, and forms can be operated without a pointer.
Check skip-to-main-content access, page title, and structured headings.
Confirm that form controls have understandable labels or accessible names, and that instructions and validation errors identify what needs attention.
Check text alternatives for meaningful images and useful status or error feedback after actions.
Try text resizing and spacing options relevant to the site, and check that content does not become clipped or obscured.
Check contrast and, where required by the team’s plan, use assistive technology such as a screen reader for the key journeys.

Automated accessibility tools can help find some issues, but pair them with manual interaction and assistive-technology checks according to the test plan. GIGW describes manual and accessibility-tool evaluation; the banking-sector guidance establishes the bank context. Neither a responsive check nor an automated scan alone certifies the whole experience. See GIGW 3.0’s scope.

4. Combine emulation with physical-device and network checks

Viewport emulation is efficient for checking layout breakpoints and quickly covering dimensions. It does not reproduce every physical-device behavior, browser variation, input method, or performance condition. Select supported browser and OS combinations from the bank’s own data, then validate the most important journeys on the physical combinations that matter to the bank’s users.

Include portrait or landscape orientation where a real task calls for it. Check realistic network conditions as a separate dimension: pages should communicate loading, success, and failure clearly, and users should not be left unsure whether an action completed. Do not use production transactions to create network failures unless the bank’s test procedures explicitly authorize them.

An Indian Bank testing-services RFP lists mobile UI and multi-device/form-factor testing alongside WAN, usability, and accessibility testing. It treats these as distinct QA concerns and cites browser developer tools as an example for WAN-related work. This is procurement evidence, not a universal legal requirement or a prescribed tool for every bank. See the Indian Bank testing-services RFP.

5. Record findings so another tester can reproduce them

Use one record per defect or test result. Capture:

Page URL or journey name, date, and test environment.
Viewport width and height in CSS pixels, orientation, zoom, and text settings.
Browser and version, operating system, device, and whether it was emulated or physical.
Network condition and relevant accessibility settings.
Expected behavior, actual behavior, reproducible steps, and screenshot evidence.
Impact or severity rationale, owner if applicable, and retest result.

Keep formal compliance criteria separate from team-selected quality thresholds. The cited documents do not prescribe a defect severity scale or a complete reporting template; the fields above are practical QA recommendations.

6. Browser-based screenshot capture for evidence

For a local manual check, open the page in Chrome or another supported browser, use its responsive device or viewport controls to set the CSS dimensions, and capture the visible state using the browser’s screenshot capability. For a full-page record, use the browser’s full-page capture feature if available. Save the screenshot with the test record, viewport, browser, and date so it is tied to the conditions that produced it. A screenshot documents appearance; it does not establish keyboard access, screen-reader behavior, or physical-device compatibility.

When evidence capture needs to be repeated across many URLs or viewport configurations, an API can make the image collection step easier to automate. Keep the actual interaction and accessibility checks in the test plan.

Or skip the browser setup

ScreenshotNeo is a website screenshot API and MCP server. One GET request can capture a URL as PNG, JPEG, WebP, or PDF; use the viewport options in the ScreenshotNeo documentation to match the CSS dimensions you need. For example, this cURL request saves a WebP capture:

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp

It accepts cookie or consent banners as a visitor and removes 60+ known consent platforms, newsletter popups, and chat widgets before capture; each step can be turned off. Bot checks and CAPTCHAs, blank pages, timeouts, failed loads, and cache hits cost nothing, and response headers identify the page verdict and billing status. Its MCP server gives AI agents tools for screenshots, page information, and PDF capture. The free plan includes 1,000 screenshots per month with no card; paid plans start at $5 for 3,000 screenshots.

Troubleshooting

Symptom	Likely cause	What to check
Horizontal scrolling at 320 CSS pixels	A wide table, fixed-width component, long unbroken string, or oversized media element.	Identify the overflowing element and check whether it can reflow, wrap, or provide an intentional accessible alternative. Record the page and viewport.
Text or controls overlap after resizing	Fixed dimensions, absolute positioning, or a layout that does not accommodate enlarged text.	Repeat with the same text-size and spacing settings, inspect the affected component, and verify the corrected layout at the same conditions.
A menu or dialog is partly off-screen	Positioning assumes a larger viewport or does not account for orientation or the on-screen keyboard.	Recheck in both the target orientation and relevant keyboard state; confirm all content and dismissal controls are reachable.
A form error is hard to find or understand	The message may not be associated with the field, visible after submission, or announced as status feedback.	Check the field label, error wording, focus behavior, and feedback with keyboard and the assistive technology in scope.
Emulated result differs from a physical phone	Emulation does not reproduce all device, browser, keyboard, or rendering behavior.	Record both environments and validate important journeys on supported physical combinations.
A screenshot looks correct but the journey still fails	Images capture pixels, not keyboard operation, screen-reader output, or successful task completion.	Run the interaction and accessibility steps directly; use screenshots as supporting evidence only.

Performance, reliability, and cost considerations

Keep the matrix focused on supported environments and risk: run broad viewport checks efficiently with emulation, then spend physical-device time on the most consequential journeys and observed customer context. Reuse a documented script and conditions when retesting so that a changed result is attributable to the fix rather than a changed setup.

Network variation can expose slow loading and unclear failure feedback, but a screenshot of one run is only a point-in-time record. Repeat intermittent failures and retain the conditions and timestamps. Choose the team’s own acceptance thresholds for loading and response; the cited sources do not provide universal performance targets.

Manual checks, device access, test-account setup, and evidence review all have costs. A screenshot API can reduce repetitive capture setup, but it does not replace browser interaction, accessibility evaluation, or bank-specific device selection. ScreenshotNeo’s published prices are Free for 1,000 shots monthly, Starter $5 for 3,000, Growth $15 for 15,000, Pro $39 for 60,000, Scale $99 for 250,000, and Business $249 for 1,000,000; yearly billing gives two months free, and every feature is on every plan. Consider capture volume and required options when estimating cost.

FAQ

Does a 320 CSS-pixel check prove a bank website is compliant?

No. It is a useful specific responsive check from GIGW guidance. Bank accessibility work needs the applicable banking guidance and a broader evaluation of the site and journeys.

Can browser emulation replace real phone testing?

No. Emulation helps cover dimensions quickly, while supported physical devices are needed to validate behavior in the actual browser and device combinations selected by the bank.

Does a screenshot prove that a page is accessible?

No. It can show visible layout issues, but keyboard, assistive-technology, labels, focus, and understandable status feedback require interaction checks.

Is GIGW itself a bank-specific regulation?

The cited 320 CSS-pixel criterion comes from government website and app guidance. The banking-sector guidance is a separate source for the banking context; consult current official instruments and the institution’s compliance team for formal conclusions.