How to Test an Indian University Website’s Admission Forms with Visual Screenshots

To test an Indian university website’s admission forms with visual screenshots, capture the same route and interaction state at a consistent viewport and zoom, then compare the captures across steps or releases. Test the whole applicant journey: instructions, registration, form fields, validation, document upload, review and correction, any payment step, final submission, and confirmation. Pair screenshots with keyboard-only checks, form behavior tests, and accessibility inspection: a screenshot records appearance, but cannot prove that a form works or is accessible.

Use the university’s current admission instructions as the source of truth for required fields, document formats, upload limits, steps, and support contacts. Requirements can change between admission cycles. This guide describes a repeatable testing method; it does not claim that any particular university portal has been tested or that following these steps alone constitutes a formal accessibility audit.

1. Prepare a safe, reproducible test run

Choose the right environment. Use a test or staging portal where possible. Before entering data, check whether the portal has a dedicated test path and whether payment or final submission could trigger a real action. Do not submit real applicant data or make a real payment as part of a visual test.
Use synthetic records. Enter made-up applicant details in test environments. Check that your sample values exercise ordinary and edge cases without identifying a real person.
Record the comparison conditions. Note the date, browser and version, route, viewport width and height, zoom, test data, and current form state. Keep those conditions consistent between captures.
Check the current cycle’s instructions. Record the institution’s current requirements for eligibility, required uploads, accepted formats and sizes, deadlines, and help channels. Do not copy upload limits or process steps from an old example.
Decide how to handle changing content. Note timestamps, rotating announcements, or other content likely to differ between runs. That helps distinguish expected changes from layout regressions.

Useful evidence is reproducible evidence. A screenshot without its route, viewport, zoom, and state may be difficult for another person to compare or reproduce.

2. Map the applicant journey before capturing

Make a list of the states an applicant can reach. The precise journey differs by university and admission cycle, so follow the current portal and instructions rather than assuming every institution has identical steps.

State to capture	What to look for
Admissions entry page	Clear route into the application, relevant deadlines or instructions, and visible help information.
Sign-in or registration	Clear labels, instructions, validation feedback, and recovery or support route if offered.
Each application step	Field labels, required-field cues, instructions, heading order, alignment, and any progress or save feedback.
Empty or invalid submission	Errors identify the affected fields and explain the problem in text, including how to correct it.
Document upload	Instructions explain what to upload and the current accepted formats and size limits; success and failure states are understandable.
Review and correction	Entered details can be reviewed and corrected before finalization where relevant.
Payment, if applicable	Any relevant amount, processing state, failure state, and next step are clear. Use a safe test path.
Final submission and confirmation	The result of the action is visible, including confirmation or a useful failure message.

Take at least one capture for every major state. For important fields, also capture an empty submission and a deliberately invalid value so that validation can be compared rather than inferred from the default view.

3. Capture consistent screenshots

Set the browser, viewport dimensions, and zoom recorded in your test notes.
Navigate to the exact route and establish the intended state using the same synthetic values and actions for each run.
Capture the full visible form state. If content extends beyond the viewport, capture the full page as well as any state where scrolling or sticky controls could affect use.
Name each file so the route or step, state, viewport, and date are clear. For example: application-step-2-invalid-1440x900-2026-10-04.png.
Repeat the same path after the change under review. Keep the test inputs and transitions the same.
Repeat at a narrow viewport and with enlarged text or zoom to inspect reflow and content visibility.

For a local browser-based workflow, Playwright can navigate a page, set a viewport, and save screenshots. This example runs against a test portal using synthetic data; selectors and routes must be adapted to the portal. It captures the initial page and an intentionally invalid submission. Use only a safe environment where the test action cannot create a real application or payment.

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

// save as admission-capture.mjs
import { chromium } from 'playwright';

const baseUrl = process.env.ADMISSIONS_TEST_URL;
if (!baseUrl) throw new Error('Set ADMISSIONS_TEST_URL to a test portal URL.');

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

try {
  await page.goto(baseUrl, { waitUntil: 'domcontentloaded', timeout: 45000 });
  await page.screenshot({ path: 'admissions-entry.png', fullPage: true });

  // Adapt this selector to a safe test form. This intentionally exercises
  // required-field feedback; it must not finalize a real application.
  const submit = page.locator('button[type="submit"]').first();
  await submit.click();
  await page.screenshot({ path: 'admissions-empty-submit.png', fullPage: true });
} finally {
  await browser.close();
}

Run it with ADMISSIONS_TEST_URL set to the test portal address. If the portal’s submit control advances to a real final action, replace the action with a safe validation trigger or use an institution-provided test workflow. A script can reliably capture a state only if it reaches that state; inspect the resulting image and check that the expected validation actually appeared.

For manual checks, a browser’s built-in screenshot command is also useful. Keep the same viewport, zoom, and state, and save each capture with enough context to identify it. Regardless of capture method, do not share screenshots containing personal information; remove or mask it first.

4. Compare visual details and behavior

Compare the same route and state side by side. Look for:

Fields or buttons that are clipped, overlap, or move unexpectedly.
Labels, required-field cues, or instructions that are missing, detached from their controls, or hard to scan.
Text or controls that become difficult to read at narrow widths or when text is enlarged.
Important instructions, upload guidance, errors, or actions hidden below the fold or obscured by sticky elements.
Errors shown far from the affected field, written unclearly, or indicated by color alone.
Changed spacing, alignment, headings, or control styles that make repeated steps harder to follow.
Unclear processing, save, upload, or submission feedback that could make an applicant think the page has stalled.
Differences in the review, correction, or confirmation state that affect what an applicant can verify before finishing.

When comparing two university portals, also compare the institutions’ own current requirements, languages, steps, upload rules, and support channels. A visual match is not the goal if their processes differ; the goal is a clear and usable presentation of each portal’s actual instructions.

5. Test keyboard access and form validation separately

Visual captures document what was rendered at a moment. They cannot establish that a keyboard user can complete the form or that assistive technology receives the right information. Perform these checks independently:

Use Tab and Shift+Tab to move through controls. Confirm the focus order follows the form’s logical order and that a visible focus indicator appears.
Use the keyboard to operate text fields, option groups, upload controls, and buttons. Confirm focus alone does not submit the form or cause an unexpected context change.
Submit incomplete and deliberately malformed values in a safe test path. Confirm the affected field is identified and the error gives a useful correction instruction in text.
Check that required instructions and upload guidance are available before the user needs to act.
Check that save, processing, upload, and submission actions provide visible feedback and that failures explain what to do next.
Before a final submission with legal or financial effect, check that the applicant can review, confirm, or correct information where applicable.

India’s Guidelines for Indian Government Websites (GIGW) call for basic form instructions at the start, including mandatory fields and required uploads; properly labeled inputs; text-described errors with correction information; and a contact or alternative help route. The guidance also warns that forms relying on JavaScript can be compromised if scripts are unavailable or validation does not run. Review the relevant [GIGW form guidance](https://guidelines.india.gov.in/guidelines/forms/) against the form in scope.

6. Inspect accessibility beyond the screenshot

Check labels, accessible names, roles, states, properties, and status updates with accessibility inspection tools and assistive technology. A screenshot cannot confirm these programmatic properties or whether screen-reader announcements occur. It also cannot prove keyboard operability.

The GIGW conformity matrix cites WCAG 2.1 checks relevant to forms, including text alternatives, structure and reading sequence, orientation and resizing, text and control contrast, keyboard operation and visible focus, error identification and labels. Its ordinary-text contrast criterion is at least 4.5:1, with exceptions including large text at 3:1. See the [GIGW conformity matrix](https://guidelines.india.gov.in/guidelines/conformance/) and the [W3C WCAG 2.1 quick reference](https://www.w3.org/WAI/WCAG21/quickref/). These criteria provide checks for a defined review; they do not by themselves establish a legal conclusion about a specific institution.

Higher-education accessibility guidance also recommends accessible admission materials, alternative communication support, application forms in multiple formats such as digital, large print, and braille, a sample filled form, and WCAG-conforming online materials and tools. Consult the [UGC higher-education accessibility guidelines](https://www.ugc.gov.in/pdfnews/5768441_Guidelines-for-Accessibility-in-Higher-Education-Institutions.pdf) for that broader context.

For each issue, keep a record with:

Page route and exact form step or state.
Browser, viewport, zoom, and date.
Synthetic test data or the class of input used, without personal information.
Steps to reproduce, expected behavior, and observed behavior.
A screenshot with sensitive details removed or masked.
Severity and whether the issue also affects keyboard or assistive-technology use.

Use the same record format for retesting so the team can tell whether the defect was fixed and whether the fix changed another state. A screenshot can support a visual defect report, but include the reproduction steps and separate interaction findings.

Screenshot checklist

Admissions entry page and registration or sign-in, if present.
Each major application step at the standard viewport.
Required-field and upload instructions.
Empty submission, invalid formats, and field-specific errors.
Upload success and failure states where they can be reached safely.
Keyboard focus on fields, option groups, upload controls, and buttons.
Save, processing, review/correction, and final confirmation feedback.
Narrow viewport and enlarged-text or zoom states.
Accessibility inspection of labels, roles, states, names, and status changes.
Reproducible defect notes, with personal information removed from evidence.

Or skip the browser setup

ScreenshotNeo is a website screenshot API and MCP server for developers. One GET request captures a URL as PNG, JPEG, WebP, or PDF. For a screenshot of a test admissions page, use the API examples below and see the ScreenshotNeo API documentation for the available parameters. Replace the URL with a safe test route; do not put applicant data in a URL.

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

import requests

r = requests.get(
    "https://api.screenshotneo.com/v1/shot",
    params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"},
    timeout=90,
)
r.raise_for_status()
open("shot.webp", "wb").write(r.content)

const q = new URLSearchParams({
  access_key: 'YOUR_API_KEY',
  url: 'https://stripe.com',
});
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(async fs =>
  fs.writeFile('shot.webp', Buffer.from(await res.arrayBuffer()))
);

Cookie banners are accepted like a visitor and removed before capture; 60+ known consent platforms, newsletter popups, and chat widgets can be removed, and each step can be turned off.
Bot checks or CAPTCHAs, blank pages, timeouts, failed loads, and cache hits cost nothing. The response includes X-Page-Verdict and X-Billed headers.
An MCP server offers take_screenshot, get_page_info, and capture_pdf tools for Claude, Cursor, and other MCP clients.
The free plan includes 1,000 screenshots a month with no card. Paid plans start at $5 for 3,000 screenshots; every feature is on every plan.

For repeatable admission checks, set the same viewport, route, and relevant capture options on each run. Screenshot capture still does not replace keyboard, screen-reader, validation, upload, or safe final-submission checks described above. Sign up for 1,000 free screenshots a month, with no card required.

Performance, reliability, and cost notes

Keep runs focused. Capture the states that matter instead of repeatedly capturing unchanged pages. A shorter, documented journey is easier to reproduce and review.
Control variability. Keep route, viewport, zoom, inputs, and state transitions consistent. Note dynamic content so it does not create misleading visual differences.
Handle slow pages deliberately. If a page loads asynchronously, wait for the relevant form state before capturing. A capture taken too early may show a loading state rather than the form. Record the condition so a timeout is distinguishable from a real empty page.
Protect evidence. Use synthetic test data and remove personal information before storing or sharing captures. Do not encode sensitive applicant data in public URLs.
Budget API use from the published plans. ScreenshotNeo lists Free at 1,000 shots per month with no card; 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. All features are on every plan. Only clean shots are billed, and cache hits are not billed.

Troubleshooting

Symptom	Likely cause	What to do
The screenshots look different on every run	Viewport, zoom, browser, test values, page state, or dynamic content changed.	Record those conditions, restore the same values and state transitions, and note expected rotating content.
The capture shows a spinner or incomplete form	The page or form content had not reached the intended state when captured.	Wait for the relevant control or message, then capture. Check whether a slow response or script error prevented the state from appearing.
The automated submit does not show a validation error	The selector may target the wrong control, browser validation may stop the action, or the form may need a different interaction.	Inspect the test page, adapt the selector and workflow, and verify the state manually. Do not assume that a screenshot of the unchanged page proves validation passed.
A visual comparison reports many irrelevant differences	Timestamps, rotating announcements, or other dynamic content changed.	Note the dynamic regions during baseline capture and compare the stable form content and state. Do not treat expected content changes as a form regression.
The error is visible but the field is still unclear to users	The error may not identify the field or explain how to correct it; the screenshot cannot verify the programmatic association.	Check the field’s label and error text visually, then inspect the accessible name and status announcement separately.
Applicants cannot complete the form by keyboard	Focus order, visible focus, control operation, or an unexpected action on focus may be wrong.	Reproduce using Tab, Shift+Tab, and keyboard activation. Log the exact control and sequence; a screenshot alone cannot establish keyboard support.
Upload instructions do not match the current process	Requirements may have changed for the current admission cycle.	Verify against the university’s current official admission instructions and update the test expectations.
A screenshot contains applicant information	Real or identifying data was used in the test state.	Do not share the unredacted capture. Replace it with a synthetic test run, or mask personal information before sharing evidence.

FAQ

Can a screenshot prove that an admission form is accessible?

No. It can document visible labels, instructions, focus indicators, or errors in a captured state. It cannot prove keyboard operation, screen-reader announcements, accessible names and roles, or programmatic status updates; test those separately.

Should every university portal have the same screenshot checklist?

Use the same core checks for reproducibility, then adapt the journey and expected requirements to that university’s current instructions. Portals, languages, steps, and upload rules vary.

Can I reuse upload size limits from another university or an earlier cycle?

No. Verify current accepted formats and limits on the target institution’s current admission portal or instructions before testing.

Does this workflow certify WCAG or GIGW conformity?

No. It is a practical testing workflow. A conformity assessment needs a defined scope and evaluation of applicable criteria, including checks that screenshots cannot establish.