Pod Request Access Landing Page - Svelte, SCSS
Design comparison
Solution retrospective
There's nothing like struggling with a challenge labeled "NEWBIE" to really knock you down a few pegs. 😅 Front-end design is one of those things I've always assumed I know how to do because it comes easier than back-end work, but this first challenge showed me all the blindspots I had.
1.) Mobile-first responsive design. I spent longer than I should've deciding on breakpoints and then constantly had to adjust them. The spacing transitioning from a desktop to an iPad was especially tricky. If anyone has tips on how to choose/maintain a uniform set of breakpoints, I'd love to hear them!
2.) Svelte. I took this chance to learn a new technology: Svelte. And I loved it! It made it easy to separate and keep track of the different components, I didn't have to worry about BEM naming conventions, and the code looks cleaner IMO. However, I wasn't able to figure out how to get the validation on the form working for when a user tries to submit an empty email address field using Svelte logic. (So you'll notice that the error is the same even though it should change.)
3.) Form validation. This was an unexpected pain point towards the end. If anyone knows how to turn off the automatic form validation error messages that come up in chrome (and overlap the CSS I wrote), PLEASE let me know. I couldn't figure out how to make only one error message come up.
4.) Hiding form labels. To fit the design, I had to hide the form label for the email address input field while also making sure screen readers could see it. I found my solution on StackOverflow, but how do most of you do it?
Thank you!
Community feedback
- @sirriahPosted almost 4 years ago
Hello, I did not see you code, but I think that answer for 3rd point is, that you have to not write type=email and require into input tag. Browser knows what it means and it tries to validate it. Nice work.
1 - @ArshKarpoorPosted almost 4 years ago
Wow!
Very Nice
1 - @bbsmoothdevPosted almost 4 years ago
Concerning the label on the email address, visually hiding it like you did is perfectly acceptable and a common solution. Really, the designer needs to be aware of these accessibility issues and integrate them into the design so we don't have to hide these things in the first place. My sense is that the designer mistakenly thinks that using a placeholder in place of a label is accessible. Besides, the placeholder should give an example of what you want the user to type in, not just restate the label, so it's not even really a proper use of a place holder.
I have seen some solutions where the developer will float the label text over the input box, as if it were acting as a placeholder, and then when the user activates the input the label floats up above the input.
One thing about your label, the for attribute needs to point to the id of the input it is labeling. So give that input an id and set the for attribute to that id.
1@lynettelopezPosted almost 4 years agoI came to the same conclusion you did in your first paragraph while coding. I went back and forth on how to keep everything accessible while still adhering to the design and ultimately just hid it. For my next challenge, though, I might just do the floating-above-the-input design you mentioned. It sounds cleaner.
Thank you!!
0
Please log in to post a comment
Log in with GitHub
Join our Discord community
Join thousands of Frontend Mentor community members taking the challenges, sharing resources, helping each other, and chatting about all things front-end!
Join our Discord