MSU Baroda Students: Making a Full Stack Internship Project Responsive and Accessible

To make a full stack project responsive and accessible, test it at fixed screen widths in your browser’s device mode, then run a short keyboard, contrast, semantics and form check, and record each result as pass or fail with a screenshot. Everything below uses free tools already inside Chrome, Edge or Firefox, so you can finish the audit within a 14-day internship without installing anything.

Why this audit belongs in your internship report

Most student projects are built and demoed on one laptop screen. A reviewer who opens the link on a phone, tabs through the page with a keyboard, or uses a screen reader will see problems you never noticed. An audit with evidence shows you can test your own work, which is a concrete full stack skill: the front end, the API responses that feed it, and the forms that send data back.

The audit below is deliberately small. It has 24 items across five areas, each marked pass or fail, and each tied to a screenshot you can paste into a report. Fixing failures and re-testing gives you a before/after story, which reads far better than a claim that the site “works on mobile”.

Tools you need (all free, all in the browser)

• Device toolbar (Chrome/Edge DevTools, press F12 then Ctrl+Shift+M; Firefox: Responsive Design Mode, Ctrl+Shift+M). Used for width tests.
• Lighthouse panel in Chrome/Edge DevTools. Its Accessibility category gives a score and a list of failed checks. Treat the score as a starting point, because automated tools catch only part of the problems.
• Elements panel contrast picker. Click a text colour in the Styles pane to see the contrast ratio.
• Accessibility tree (Elements panel, Accessibility tab) to check names and roles of buttons, links and inputs.
• Your keyboard. Tab, Shift+Tab, Enter, Space and Esc are the whole test kit for the keyboard section.
• Browser zoom at 200% and a text-only size increase in browser settings.
• Screenshot tool: DevTools “Capture screenshot” or “Capture full size screenshot” from the three-dot menu in device mode.

Day-by-day plan to fit a 14-day internship

The free two-week online internship from CareerSwami runs for 14 days, so the audit should be a slice of your project time, not a separate project. One workable split:

1. Days 1-8: build the core feature (pages, API, database). Write mobile-first CSS from the start so you are not retrofitting.
2. Day 9: run the full audit and record every result, including failures, with “before” screenshots.
3. Days 10-11: fix failures, starting with layout and keyboard problems.
4. Day 12: re-run the audit and capture “after” screenshots.
5. Days 13-14: write the report, record a short demo, and submit.

Responsive layout: what to test and how

Responsive does not mean “looks fine on my phone”. It means the layout adapts across a range of widths without horizontal scrolling, overlapping, or unreadable text. Start with this HTML in the page head, because without it phones render the page at desktop width:

<meta name="viewport" content="width=device-width, initial-scale=1">

Then test at these widths in device mode (they are common reference points, not a complete list of devices):

CSS patterns that fix the most common layout failures

• Use max-width: 100%; height: auto; on images so they never overflow their container.
• Use CSS Grid with repeat(auto-fit, minmax(240px, 1fr)) for card lists instead of fixed column counts.
• Use relative units (rem, %, clamp()) for font sizes and spacing instead of fixed pixels everywhere.
• Wrap wide tables in a container with overflow-x: auto so only the table scrolls, not the page.
• Collapse the navigation into a toggle button below a breakpoint, and make that button a real <button>.

The pass/fail audit checklist with screenshot evidence

Copy this table into your report. Mark each row Pass or Fail, add a short note, and attach the screenshot named in the last column. “Fail” rows that you later fix should show both a before and an after image.

Worked example: auditing a student task-manager app (illustrative)

This is an illustrative scenario, not a recorded test result. Suppose a student builds a task manager with a React front end, an Express API and a database. Rows below show how the audit might read and how to write it up.

1. Check 2 (320 px): Fail. The task table is wider than the screen, so the whole page scrolls sideways. Fix: wrap the table in a container with overflow-x: auto, or switch to stacked cards below 600 px. Re-test and mark Pass.
2. Check 10 (focus): Fail. The stylesheet contains outline: none on buttons. Fix: remove it, or replace it with a clear :focus-visible style.
3. Check 18 (real buttons): Fail. The “Delete” control is a div with an onClick handler. Keyboard users cannot reach it. Fix: change it to <button type="button">.
4. Check 19 (labels): Fail. The “Add task” input uses only placeholder text. Fix: add a <label for="task-title"> and matching id.
5. Check 21 (API failure state): Fail. When the server is stopped the list area is blank. Fix: show “Could not load tasks. Try again.” with a retry button.

In the report, a single line per fix is enough: the check number, what failed, the code change, and the before/after screenshots. This also shows that accessibility reaches the back end, because the API error format decides which message the user sees.

Back-end and data details that affect accessibility

• Return field-level validation errors from the API, for example {"errors": {"email": "Enter a valid email address"}}, so the front end can attach messages to the right input.
• Use proper status codes (400 for invalid input, 401 for unauthenticated, 500 for server errors) so the interface can show a useful message rather than a generic failure.
• Paginate long lists on the server. Huge responses slow low-end phones and make keyboard navigation painful.
• Move focus after actions. After a successful add or a failed submit, send focus to the confirmation or the first error so keyboard and screen reader users know what happened.

A quick screen reader pass

Automated tools cannot judge whether the page makes sense when read aloud. Windows users can try NVDA (free), and Android phones include TalkBack. Spend ten minutes on one core task, such as adding an item. Listen for unlabelled buttons, unclear link names and silent changes. Note two or three findings in the report; you do not need to claim full screen reader compliance.

Applying this audit as an MSU Baroda student

Your report may be read by more than one audience: the internship provider, and possibly your own department. At MSU Baroda, the rules for the second audience are not uniform, so check them before you decide how to present the work.

The university posted a circular titled Internship Document, Faculty of Commerce 2025-26 with an attached PDF. The circular page carries no description, so duration, credits, evaluation and treatment of online internships should be treated as unverified until you read that document. Since it is issued by one faculty, internship rules may be set per faculty rather than in one university-wide document; confirm this for your own faculty instead of assuming it.

The university also has an Office of Career Advancement for Students, which lists a Career Counseling and Training & Placement Cell and a Students’ Internship and Mentorship unit with Students’ Apprenticeship. Those are sensible places to ask how an online internship and its report should be documented. Examination matters, by contrast, are handled centrally: the Examination Section page lists ordinances such as Ordinance 282 (amended). Do not assume that such ordinances say anything about internship reports.

A free CareerSwami offer letter and completion certificate can support your own records, but this guide does not claim that your department will give credit for them. Whether they count for anything is your faculty’s decision.

Verification steps for MSU Baroda students on internship reports

1. Open the Faculty of Commerce internship circular if you are in that faculty, download the PDF, and note duration, evaluation and documents required.
2. If you are in another faculty (Technology and Engineering, Science, Management and so on), ask your department office or internship coordinator in writing whether an internship document exists for your programme and year.
3. Ask in writing: “Is a 14-day online internship acceptable for my programme, and what report format and evidence are needed?”
4. Ask the Students’ Internship and Mentorship unit listed on the career office page whether they need a letter, certificate or report copy.
5. Check the university’s central Academic Calendar link in the site header, and your faculty’s own calendar, before fixing your 14 days around exams or breaks.

Writing the audit report

Keep the report to four to six pages. A structure that works:

1. Project summary: what it does, the stack, and the live or local URL.
2. Method: browser and version, tools used, widths tested.
3. Results table: the 24-item checklist with Pass/Fail before and after.
4. Fix log: one short entry per fix with before/after screenshots.
5. Known limits: what you did not test, such as other browsers or real devices.

Name screenshots consistently, for example 05-width-320-before.png and 05-width-320-after.png, so a reviewer can match them to the checklist. Crop to the relevant area and add a one-line caption.

Frequently Asked Questions

Is a Lighthouse score of 100 enough to call my project accessible?

No. Lighthouse automates only a portion of accessibility checks. It cannot judge whether alt text is meaningful, whether the focus order makes sense, or whether error messages are helpful. Use it alongside the keyboard and contrast rows of the checklist.

Do I need a real phone to test responsiveness?

Device mode is enough for layout checks, and it is what this checklist assumes. If you can also open the deployed project on a real phone, add one photo or screenshot, and say in the report that it came from a physical device.

What contrast ratio should I aim for?

The commonly used WCAG guideline is at least 4.5:1 for normal-sized text and 3:1 for large text. The DevTools colour picker shows the ratio for the colour you select.

Can I use a CSS framework like Bootstrap or Tailwind?

Yes, but the framework does not make a project accessible on its own. You still have to use real buttons, labels, headings and visible focus styles, and you still need to run the audit.

How should I handle failures I could not fix in time?

List them honestly under known limits, with the check number, the cause and the fix you would try next. A documented open issue is better than a hidden one.

Will my college give credit for this internship project?

That depends on your faculty and programme. Credit rules are not something this guide can confirm, so ask your department in writing and check any internship document your faculty has published.

Does the CareerSwami internship include a stipend or a job?

No. It is a free two-week (14-day) online internship with a free offer letter and a free completion certificate after successful completion, across 26 tracks. It does not promise a stipend, credit or placement.

Should the audit cover the back end too?

Partly. The API affects accessibility through its error messages, status codes, response size and loading behaviour, which is why rows 20 and 21 are in the checklist.