Feedback - Registration form

Hello everyone. Would like to have some feedback and recommendations for the registration form that I’ve built. Here is the codepen link:
https://codepen.io/rreiso/full/MWbbVMa
Honesty and details welcome. I’m here to learn and improve.

Your form looks good @RReiso. Some things to revisit;

  • Run your HTML code through the W3C validator.
    • There are HTML coding errors you should be aware of and address.
    • Since copy/paste from codepen you can ignore the first warning and first two errors.
  • Do not use the <br> element to force line breaks or spacing. That’s what CSS is for.
  • User’s should be able to click on the label to toggle a selection, not just the radio button / checkbox
    • you have a cut/paste error. To see what I mean click the label for ‘arrangement’ and notice which checkbox toggles

You really have an eagle eye for noticing that toggle issue. Thanks for pointing it out.
I did use W3C validator, but afterwards I changed some things again and forgot to recheck.
I also got rid of <br> tag, hopefully in a proper way.
Thank you for your feedback.

1 Like

@bbsmooth I love your on-point feedback on this forum. Would be grateful if you could take a look at my form as well.

Hey @RReiso, overall this is very nice. I’m mesmerized by the background :slight_smile: I’m going to get a little picky here since you seem to have a good grasp on things, so you can start concentrating on the smaller details.

  • You have set a custom focus indicator which is great. I always do that because usually the browser’s default focus indicator is not adequate. But it’s not applied to the radio buttons/check boxes. I know that using the outline property on these is ugly but there are other methods to make it look nicer. Without using JS, I think the best alternative might be to use a box-shadow. (Which I now just realized is what you are doing for all of the other inputs).
  • Also, the Register button needs a focus indicator (you’ve set outline: none on it).
  • The <h3>s should probably not be headings as they aren’t really acting as a heading for content but rather just words in the logo.
  • Speaking of that logo, I’m not sure I would understand its purpose if I were using a screen reader. The reader would announce the heading at the top, and then the instructions, which is great, but then it would suddenly announce “Sweet”, “Muffin”, “Retreat” and then move onto the form. Is “Sweet Retreat” the name of the business that is hosting the decorating class? If so, this seems like pretty important information to know. I would be tempted to make this part of the <h1> (e.g. “Sweet Retreat’s Cake Decorating Masterclass”) and then hide the logo from screen readers completely by using aria-hidden="true" on the logo div. I am being very picky here for sure. I’m just pointing out that the content on your page should make sense to people who can’t see it (only hear it), so logical order of content is very important.
  • Great job on the <label>s, you got them all (most of these I see almost always forget them for the <select> and <textarea>).
  • If you use an automated accessibility checker on your page it is going to complain about not having a <main> around the form, so I would add that.
  • The two social media links at the bottom of your page need to have some text associated with them (primarily for those pesky screen readers again). The easiest way to do this is to add the text inside the <a> and then visually hide the text. You could also use the visually-hidden trick on the <h1> to add “Sweet Retreat’s” to the beginning of the heading for screen readers.
  • The responsiveness to changes in view port width is pretty good, I’m not getting any horizontal scroll bars. Being very picky now. As I’m narrowing the browser, the form continues to narrow as well, and then when I reach the min-width: 481px break point the form suddenly gets wider because max-width on the container has changed from 70% to 90%. It seems a little odd that the form would be skinnier at a wider view port width, especially when the browser is already very narrow and you need as much horizontal room as you can get. I personally would not use a percentage for the max-width. I’d use em units instead, that way the form will scale to the font size instead of the browser width. Also, you can just have one global max-width on the container and don’t need to worry about changing it for each break point. You can add side padding to body to keep the form from getting too close to the browser edge.
  • Responsiveness to text size changes isn’t quite as good though. In general, your page should be able to handle up to a 200% increase in text size gracefully. It’s not terrible, I can still read all of the content for the most part (which is probably the most important issue), but if you are a perfectionist like me then you wouldn’t be happy when content started unnecessarily breaking out of its container. If you don’t know how to increase the text size only, search for ‘zoom text only [your browser]’. The important word here is “only”. This isn’t regular page zoom that is enabled by default in most browsers. This is only changing the text size on the page. One of the best ways to deal with text size only increases is to use em units instead of px units for your break points. You can ballpark the initial conversion by dividing the px value by 16. So crank that text size up to 200% and test at all widths.

Again, I am being very picky about some things above. Overall this is very nice.

1 Like

@bbsmooth, Thank you so much for your time and effort you’ve put into this. :clap: Wonderful information and tips. I am currently googling and reading many things you are mentioning, accessibility is a huge area on its own. I will get back once I’ve made changes.
P.S. I appreciate the friendly manner you are giving your feedbacks, so no one really feels criticized. (I think so :slightly_smiling_face:)

@bbsmooth, these are the things that I tried to improve:

  1. Added box-shadow to focus-indicators on check-boxes, radio-buttons and register button.
  2. For the business logo, I changed the ­<h3> s to <p>s and hid the logo from screen-reader.
  3. Added business name to the title, wrapped it up in a <span> and set the class to “sr-only”.
  4. Added some descriptive text to the footer links and added the class=“sr-only”.
  5. The properties for sr-only class I found here:
    WebAIM: CSS in Action - Invisible Content Just for Screen Reader Users
.sr-only {
	position: absolute;
	left: -10000px;
	top: auto;
	width: 1px;
	height: 1px;
	overflow: hidden;
}

Another option I found here:
https://codepen.io/ffoodd/pen/gwKZyq?editors=1100

.sr-only {
	border: 0 !important;
	clip: rect(1px, 1px, 1px, 1px) !important; 
	-webkit-clip-path: inset(50%) !important;
					clip-path: inset(50%) !important;  
	height: 1px !important;
	overflow: hidden !important;
	margin: -1px !important;
	padding: 0 !important;
	position: absolute !important;
	width: 1px !important;
	white-space: nowrap !important;       
}

Which one is better, I have no idea. I used the first one.

  1. Changed max-width units in container and media queries to ems.

  2. I zoomed in ‘text only’ using Mozilla Firefox. If you make the browser window very narrow, the title text will overflow the container, I don’t know if something can be done about it ? , the words are long and huge.

There are many versions of this technique. They are probably all the same as far a effectiveness.

I almost wrote something about this in my original post but I decided to let you “discover” it for yourself :slight_smile:

There are some options. If the word has a natural break point (like Masterclass could break at “Master” and “class”) then you can add a <wbr> in between those two words. There is also &shy; (soft hyphen). There are also some CSS properties that can break words up (e.g. word-break or hyphens). But ya, sometimes you’ll just have to live with a small scroll bar when the text is 200% and the view port is very narrow. Realistically, there probably won’t be many users with that combination and I’m guessing they will be used to getting scroll bars anyway.

Great job!

1 Like

Hey RReiso, just wanted to say that I think your form site looks amazing!! And thank you for sharing it- I learned a lot about organization, attributes, and CSS properties just going through your code. Cheers!

1 Like

hey @bobericksonjr89, that is so nice to hear. I’m learning myself, but happy that you could benefit from my project as well :slight_smile:

1 Like

thank you @bbsmooth, I added some &shys, so my form can shrink now more without text leaving the container. I hope the &shys don’t come with other unexpected behaviours.
You mentioned in your original feedback:

Could you please elaborate, what can trigger those? I don’t know what did I do to avoid them…

What triggers a horizontal scroll bar is any element that is wider than the view port. This can happen for a variety of reasons, too many to list here, but if you are getting a horizontal scroll bar then just use your browser’s dev tools inspector to figure out which one is wider than the view port. Sometimes it will be obvious and other times it could be caused by some excess side padding/margin that you can’t see until you use the inspector.

Using a narrow-first approach to styling will definitely help you avoid the dreaded horizontal scroll bar much easier.

Good to know. That’s exactly how I’m trying to build my projects - from narrow screen to wider one.