Visual Autograder for HTML and CSS Assignments That Grades What the Page Looks Like

The problem: web assignments are graded by eye, slowly

Web development courses at Pakistani universities and bootcamps are large. A teacher may set an assignment like "build this landing page from the design" for 150 students across three sections. Marking means opening each submission, resizing the browser, comparing it with the design by eye and writing a few comments. It takes days, the marks vary between teaching assistants, and students get feedback after they have moved on.

Unit tests do not help much. A test can check that an element exists, not whether the layout matches, whether the page works on a phone, or whether the heading is the right size. Teachers end up choosing between tests that miss what matters and manual marking that does not scale, and many quietly reduce the number of assignments as a result.

What already exists and the gap

• GitHub Classroom supports autograding through tests and scripts that run on each push.
• Gradescope, CodeGrade and similar platforms run code autograders and support manual rubric marking with annotations.
• Visual regression tools such as Percy and Chromatic compare screenshots of the same app between versions. They flag pixel changes, which is far too strict for 150 different student implementations of one design.
• Accessibility checkers such as axe-core find rule violations but say nothing about the layout.

The gap is a grader that understands "close enough" for layouts: it matches blocks of content between two different implementations and scores how similar they are, the way a teacher would judge.

Inspiration

Design2Code (Si et al., 2024, Stanford and collaborators) built a benchmark of 484 real webpages to test whether multimodal models can turn a screenshot into code. To score the results, the authors designed metrics beyond pixel comparison: overall visual similarity plus matching of visual elements, and text, position and colour similarity between matched blocks. Those metrics fit student grading almost perfectly. Your project turns them into a teaching tool and checks whether they agree with human markers.

What you build

• Teachers upload the target design (as a reference HTML page or a set of screenshots), choose screen sizes and weights, and connect the class repository or a ZIP of submissions.
• Students push their work and get a feedback page within minutes: a score per criterion, overlays showing differences and a list of accessibility issues.
• Teaching assistants review only borderline cases flagged by the system.

The technically interesting part

• Matching blocks between different pages. Extract visible text blocks and their boxes from both pages, then match them with text similarity and position, as Design2Code does. Unmatched blocks become "missing" or "extra" content.
• Tolerance. A layout 10 pixels off is fine; a sidebar on the wrong side is not. Scale tolerance by element size and screen size, and let teachers adjust it.
• Fair rendering. Fonts, image loading and animations make screenshots unstable. Load fonts locally, disable animations and wait for the network to settle.
• Responsive checks. Score each breakpoint separately, because many students only test at one width.
• Gaming the grader. Students will try a screenshot of the design as a background image. Detect this by checking that matched text is real text in the DOM, not pixels.
• Explaining the score. A number alone is not feedback. Generate overlays and short notes such as "the call-to-action button is missing on phone width".

How to evaluate it

• Agreement with teachers: collect 100 past submissions with teacher marks (with permission) and report correlation between automatic and human scores per criterion.
• Consistency: grade the same submission ten times and confirm the score does not change.
• Speed: time to grade a class of 150.
• Student usefulness: survey a class that used it, and compare resubmission improvements with a class that did not.

Suggested plan

• Weeks 1 to 3: read Design2Code, collect past assignments and marks.
• Weeks 4 to 7: rendering, block extraction and matching.
• Weeks 8 to 10: metrics, tolerance, accessibility checks and feedback overlays.
• Weeks 11 to 13: GitHub Classroom integration, teacher dashboard and grading runs.
• Weeks 14 to 15: validation study, write-up and demo.

Path to a product

Universities, bootcamps and online course providers all teach HTML and CSS at scale. A hosted grader with a free tier for teachers and paid plans for institutions is a familiar model, and LMS integrations increase its value. The validation study makes a good paper for a computing education conference, and the project is a strong portfolio piece for frontend and education technology roles.

Scope warning

Do not try to grade JavaScript behaviour in the first version; static layout and accessibility are enough for a full project. Use teacher marks as the ground truth and report disagreements honestly. The grader should support teachers, not replace them, so always let a human override the score.

Learn what you need on Sefism

• Frontend development roadmap: the layout and CSS concepts you will grade.
• Learn CSS: to write the rubric and understand common student mistakes.
• Learn Responsive Design: breakpoints and why many submissions fail on phones.
• Playwright Documentation: stable rendering and screenshots.
• WAVE Web Accessibility Evaluation Tool: what accessibility checks catch in practice.

Get help with this idea

The risk is a grader whose scores teachers do not trust. Tauseef can help you plan the validation study, choose tolerances and find a course willing to pilot it. If you are new here, create a free account first.

• Discuss this idea with a mentor
• Send a query to Tauseef
• Book a 1:1 session