feat: implement progressive form disclosure with gender identity elig…

[kabugatti]

📝 Description

This PR implements progressive form disclosure improvements following the UK Government's "one thing per page" philosophy. The application form now starts with a gender identity eligibility check to quickly filter candidates and save time for non-eligible users. All external JavaScript and CSS dependencies have been moved inline, and conditional logic prevents front-loading of requirements text.

This addresses the follow-up work requested in issue #567 for iterating on PR #538, specifically implementing Derek Houck's suggestions for form improvements.

🔂 Changes Made

Frontend/Templates:

• Progressive Form Structure: Restructured templates/app/form.html to implement step-by-step disclosure
  • Step 1: Gender identity eligibility check with immediate filtering
  • Step 2: Main application form (shown only for eligible candidates)
  • Non-eligible message: Respectful redirect with alternative engagement options

JavaScript Improvements:

• Moved inline: All functionality from /static/js/form.js is now embedded directly in the template
• Enhanced eligibility logic: Smart keyword matching for custom gender identity responses
• Progressive step management: Clean transitions between form steps
• Improved validation: Visual error indicators with scroll-to-error functionality
• Accessibility: Enhanced Learn More expandable sections with proper ARIA support

CSS Improvements:

• Moved inline: All styles from /static/css/forms.css are now embedded in the template
• Modern responsive design: Mobile-first approach with touch-friendly interactions
• Progressive form styling: Clear step indicators and visual hierarchy
• Error handling: Visual error states with red borders and inline messages
• Cross-browser compatibility: Consistent styling across all modern browsers

User Experience:

• Early qualification filter: Gender identity question saves time for non-eligible users
• Conditional logic: No more walls of eligibility text shown upfront
• Clear progression: "Step X of Y" headers guide users through the process
• Helpful guidance: Expandable explanations for complex questions
• Respectful messaging: Polite alternatives for non-eligible candidates

⚙️ Related Issue

• Issue Number: Handle Form Structuring & Conditionals #567

🍏 Type of Change

• New feature
• Refactoring
• Bug fix
• Documentation update

🎁 Acceptance Criteria

• JavaScript moved from external script to inline implementation
• CSS moved from external SASS file to inline styles
• Gender identity question implemented as first eligibility filter
• Progressive disclosure prevents front-loading of requirements language
• "One thing per page" philosophy implemented with clear step progression
• Non-eligible users receive respectful message with alternatives
• Form maintains existing validation and accessibility standards
• Mobile-responsive design works across all devices
• No external dependencies for form functionality

🧰 New Environment Variables or Requirements

No new environment variables or dependencies introduced. This change actually reduces external dependencies by moving JavaScript and CSS inline.

🧪 How to test

1. Navigate to the application form: Visit /app-form route
2. Test eligibility filtering:
   • Select eligible gender identities (Cis Woman, Trans Woman, Non-binary/Genderqueer, Agender/Genderless, Genderfluid)
   • Verify Step 2 displays with full form content
   • Select non-eligible options (Cis Man, Trans Man)
   • Verify respectful redirect message appears
3. Test custom gender identity:
   • Select "Other" and enter custom responses
   • Test keyword matching (e.g., "woman", "non-binary", "female")
4. Test form functionality:
   • Complete Step 2 form fields
   • Verify validation works (required fields, error messages)
   • Test expandable "Learn More" sections
5. Test responsiveness:
   • Verify form works on mobile, tablet, and desktop
   • Test touch interactions and keyboard navigation
6. Test accessibility:
   • Use screen reader to verify ARIA labels
   • Test keyboard-only navigation

🚀 Deployment Notes (if applicable)

No special deployment steps required. The changes are self-contained within the template file and do not require:

• Environment variable updates
• New library installations
• Database migrations
• Server configuration changes

📸 Demo

Screencast.From.2025-10-14.18-22-00.mp4

✅ Checklist

• I have performed a self-review of my code.
• My code follows the style guidelines of this project.
• I have commented my code where necessary.
• I have tested my code locally and verified the website is working as expected.
• (if applicable) I have added documentation in the README.
• (if applicable) I have added tests that prove my fix is effective or that my feature works.
• (if applicable) New and existing unit tests pass locally with my changes.

🔄 Additional Notes

This implementation follows best practices from the UK Government Digital Service for form design and successfully addresses all requirements outlined in issue #567. The progressive disclosure approach improves user experience for both eligible and non-eligible applicants while maintaining the integrity of Techtonica's application process.

[MichelleGlauser]

Could we change out the recommendation that rejected people follow us with learning resources such as freeCodeCamp and our curriculum?

[monikkaelyse]

Is it possible to make the dropdown larger? It seems to be quite small

For reference, this is what the other dropdowns on the form look like

It also doesn't appear to be responsive, I believe it should be on the next line and not the same line as "learn more"

Additionally, the form does not seem to fit inside the container when mobile

Please let me know if you can address these issues or have any questions!

@kabugatti

[kabugatti]

@monikkaelyse It's possible, I'll check it out then get back to you.

[kabugatti]

Here's how step 1 looks like

In mobile view

Removed extra border in step 2

[daaimah123]

For more context about @MichelleGlauser's comment above, you can replace the content of the rejection screen with the following

Thank you for applying for Techtonica. We are unable to move forward with your application at this time. While we cannot share specific feedback on your application, we would like to support your continued learning journey about software engineering.

We encourage you to continue learning JavaScript, practicing talking through your work, presenting in front of people, building confidence, taking the initiative to learn on your own, and collaborating empathetically with others. Here are some resources we recommend:

• freeCodeCamp
• Toastmasters
• Women Who Code
• Codecademy
• Techtonica events (monthly study groups) and curriculum

Wishing you the best on your journey.

[kabugatti]

Updated rejection text

[monikkaelyse]

@kabugatti It appears this work was done directly in the mvp branch so I'm having some issues with my local remotes trying to pull orgin/mvp vs kubugatti/mvp.

Note: This resolved the issue above BUT I'm seeing all of these changes in our main mvp branch now which doesn't seem right because this isn't merged in?

git fetch origin
git branch --set-upstream-to=origin/mvp mvp

@daaimah123 Are you seeing this locally as well? Should this work be done in a feature branch off of the mvp branch to be merged in instead?

It appears that the rest of the forms have some CSS changes that appear to be new and I'm trying to figure out what was introduced here (vs what it used to look like).

[monikkaelyse]

See previous comment about branching

[daaimah123]

Closing with updated branching ownership in new PR (#869).