What to know
Before entering a development award, test the public URL, core journeys, forms, responsive layouts, keyboard access and performance. Provide accurate project credits and explain technical decisions with observable evidence. Remove broken interactions and make sure reviewers can reach the work without unnecessary barriers.
The worst time to discover your contact form fails is when a reviewer uses it. The second worst time is after the site has gone live and customers have been using it for weeks.
An award entry should be the final check on a well-built product, not the first time anybody has tested the experience outside the development team.
The Web Dev Awards judging framework examines technical execution, performance, accessible interaction and creative development. Use those same ideas to organise a practical pre-submission review.
1. Test the real tasks
Write down the three most important tasks a visitor should complete. For a hospitality website that might mean finding room information, starting a booking and contacting the property. For a SaaS product it might mean creating an account, completing an onboarding step and returning to saved work.
Complete each task on a phone and a desktop browser. Then intentionally make a mistake. Submit an empty form. Use the back button. Interrupt a request. Good interfaces explain what happened and how to recover.
2. Check keyboard interaction, not only colour contrast
Start at the browser's address bar and use Tab, Shift+Tab, Enter and Escape where appropriate. Does focus remain visible? Can menus open and close? Can someone reach the primary action without using a pointer? Do modals return focus to the right place when dismissed?
Read labels out of visual order and check whether the content still makes sense. Automated tools can detect some issues but not whether the actual journey is understandable. That requires manual testing.
3. Test layout and motion under constraints
Reduce the viewport width. Increase text zoom. Try long navigation labels and missing images. Check whether decorative motion honours the user's reduced-motion preference.
A custom transition should help explain context, not force the visitor to wait. If it adds seconds but no understanding, reconsider it. Awards about creative engineering may appreciate difficult techniques, but there is still a person on the other end of the screen.
4. Make performance part of the build
Run PageSpeed Insights on representative pages, not only the homepage. Review real-user metrics where available and distinguish them from laboratory tests. Examine the largest visual element, layout shifts, scripts that block interaction and heavy third-party tags.
For a site with striking motion, document why the effect is necessary and what fallback exists when hardware is limited. Complexity is not a virtue when it reduces access.
5. Verify semantics and discoverability
Check heading structure, meaningful link text, form labels and the relationship between visual order and document order. Confirm that canonical metadata, robots directives, redirects and important pages behave as intended.
Not all awards focus on SEO, but a broken sitemap or accidental noindex directive is a preventable production problem. A complete project should not rely on a reviewer using exactly one browser and one screen size.
6. Prepare the actual submission evidence
Keep a short technical explanation under five headings: problem, audience, approach, constraints and result. Include the live URL, correct contributor credits, any access instructions and screenshots that reflect the submitted version.
Do not invent performance numbers. If you cite a benchmark, say which page, test condition and date it came from. If you share a conversion outcome, explain the period and measurement method.
7. Choose an evaluation that matches the work
Web Dev Awards is particularly relevant when implementation is central. A project with exceptional art direction might also suit CSS Awards. British projects may consider Web Awards UK, while concept-led international work can be compared with Global Web Awards and World Web Awards.
The technical review is the same work you should do for your users anyway. An entry fee should never be treated as a way around quality checks.
Quick checklist
- Navigation and primary actions tested on mobile and desktop
- All relevant form success and failure states checked
- Keyboard focus and controls reviewed manually
- Reduced-motion behaviour verified where motion is used
- Content readable at higher zoom and narrow viewports
- Performance checked on representative internal pages
- Important URLs, redirects and indexing controls verified
- Credits, permissions and entry details accurate
- Evidence reflects the actual deployed website
FAQ
Does a good Lighthouse result guarantee a strong award review?
No. It is one useful diagnostic. It does not evaluate all usability, accessibility, content or design decisions.
Can an experimental website still be accessible?
Often yes, but the team needs to consider input methods, motion preferences, readable content and sensible fallbacks as part of the concept.
Should developers submit the repository?
Follow each award's requirements. A clear technical explanation and a working live experience are usually more useful than a large code dump without context.
A disciplined pre-submission check makes for better awards entries. More importantly, it makes for better websites.
Read next: developer-focused website awards.