Beta Survey Form submission

Very basic survey form to fufil the test requirements for the beta.

Any feedback is appreciated. Still working on the styling but would like peoples opinions.



there is a point to keep forms basic I think:) looks good for me, and html with comments is clean and easily readable, mine is never like that:smiley:

On a wider screen, it looks a little odd to have everything pushed over to the left side of the grey container.

Why not change remove the grey container’s width property and add text-align:left; and display: inline-block; to it. Also, so that the container remains centered on the page, you should add text-align:center to your body selector.

Making the changes I suggest above changes your look to the following on wide screens

It also still looks good on mobile.

1 Like

Thanks, I have made the changes you suggested and it looks miles better.

@angelinalblyth This is a good start. :stars: Here are some of my thoughts:

  • Unused Classes in HTML: I notice the row, col-25, and col-75 classes in the HTML but don’t see them being used in the CSS. I’m guessing these are for future use, but just in case they were left in by accident, I’m pointing them out here.

  • Form Element Connection to Labels: I see a few issues where there are either no label elements or there is a label, but the association between the label and the form element isn’t correct. In the Improve Form Field Accessiblity with the Label Element challenge, it mentions that every form element needs a label. The association between the label and the form element (not mentioned in the challenge) can be explicit, using the for attribute in a <label>, or implicit by wrapping form elements within the <label> element.

    The value of the for attribute must be the same as the value of the id attribute of the form control. Here’s an example:

      <label for="name">Name:</label>
      <input type="text" id="name" name="name-field">

    This is an example of an explicit association between the <label> and <input> elements. Even in the case of an implicit association where a for attribute is not necessary, MDN still recommends it:

    Note that a widget can be nested inside its element, like so:

       <label for="name">
         Name: <input type="text" id="name" name="user_name">

    Even in such cases however, it is considered best practice to set the for attribute because some assistive technologies do not understand implicit relationships between labels and widgets.

    Another reason to add labels to all of the form elements is that when one clicks on the label, the form element will be selected. You can see this when you click on the word Name: or Email: in your form. You’ll see the cursor go into the text field. However, if you click on the Male, Female, Yes, or No words, nothing happens because those don’t have labels or aren’t associated with labels.

  • Fieldset and Grouping: In the Wrap Radio Buttons in a Fieldset Element for Better Accessibility challenge, it states:

    Since radio buttons often come in a group where the user must choose one, there’s a way to semantically show the choices are part of a set.

    The fieldset tag surrounds the entire grouping of radio buttons to achieve this. It often uses a legend tag to provide a description for the grouping, which is read by screen readers for each choice in the fieldset element.

    In your project code, the gender radio buttons probably don’t need to be wrapped in a fieldset with a legend. However, the Are you enjoying this? checkboxes probably should be wrapped in a fieldset which includes a legend element because screen readers will only read the yes and no options. The user will not know what they’re being asked.

    Also, from a logical perspective, I guess it’s possible for one to answer yes AND no to that question, however, I’m not sure if that’s very meaningful. I know this project isn’t meant to critique the content of the questions on the form, however in this case, I think it’s helpful to point out that yes/no questions should more often be radio buttons as opposed to checkboxes.

Overall, this is a good start. Keep up the good work! :sunny:

Thanks for the input. I didn’t realise I hadn’t matched up the for with id’s, changing that now.

@angelinalblyth IMHO, most of the <div>s in your form are unnecessary, you can simply style your <label>s and <input>s with display: block;.

Also, let me sum up @camper’s points about labels and fieldsets. Take the gender radio button group as an example: What you are trying to do with adding the same ID to both radio buttons so they both match up to the label’s for attribute is invalid because IDs must be unique. Also, the word “Gender” does not play the role of a label to any particular radio button, rather it’s “Female” and “Male” respectively. These words are not being properly associated with their radio buttons when you just place them in the same div.

Here is how I would do it (I’m sure it’s not the only way):

<fieldset> <!--This element creates a group of related form controls-->
    <legend>Gender:</legend> <!--This is a caption that explains the relationship between the controls-->        
    <input type="radio" name="radio-buttons" value="Female" id="female">
    <label for="female">Female</label> <!--Puts "Female" inside a label that is related to the female radio button-->
    <input type="radio" name="radio-buttons" value="Female" id="male">
    <label for="male">Male</label> <!--Puts "Male" inside a label that is related to the male radio button-->

You will prbably not like the default styling of fieldsets and positioning the legend can be a bit of a challenge. For me this was where HTML and CSS became interesting.

Happy coding…

Where did you learn to use drop downs? It isnt taught in FCC is it?

I cant remember off the top of my head if it is or not. Im pretty sure I followed the W3Schools method for datalist