Skip to content
  • Unlock Pro
  • Log in with GitHub
Solution
Submitted over 2 years ago

“Mobile-first solution using CSS Flexbox and javascript

accessibility, bem
Jungsu-Jung•30
@wjdwjdtn92
A solution to the Interactive rating component challenge
View live sitePreview (opens in new tab)View codeCode (opens in new tab)
Code
Select a file

Please log in to post a comment

Log in with GitHub

Community feedback

  • Grace•32,130
    @grace-snow
    Posted over 2 years ago

    Hello

    This looks pretty good but there are some problems

    1. Height 100vh is causing the body background to stop before the content on mobile landscape. Use min height instead
    2. Never ever use width 100vw. All that does is cause horizontal scroll in some views because whenever there is a scrollbar present, you are effectively telling the browser you want the body to be "100% wide PLUS the width of the scrollbar). Viewport units don't account for things like that. You don't need a width on the wrapper at all. It's full width anyway
    3. It's not good practice to load 3 separate css files, especially on a tiny challenge like this. Combine into one for good performance
    4. Never style on IDs. It's not what they're for and is messing with the css specificity tree in your styles. Similarly you are nesting selectors a lot here. That will become impossible to manage on bigger projects. Use single class selectors as much as possible and try to keep css specificity low / flat
    5. There's no need to give main a min width (or a min height actually)
    6. Font size must NEVER be in px, even in your css reset. This is extremely important. That has immediately made this inaccessible to some users
    7. In html if decorative svgs are inline they must have aria-hidden="true" focusable="false". In fact its good t I do that on any inline svgs including meaningful ones and label them with separate text if they are meaningful
    8. Remove aria-label="submit button". That is already a button and already has text inside saying submit. The golden rule of aria is to only use it when needed.
    9. If you do want to add some aria an important place to add it would be aria-live="polite" on an additional wrapping element eg div around the thank you content. This would tell the accessibility api to effectively watch for changed. When that thank you content gets displayed it will them be immediately read aloud

    Nice job on the javascript. It's optional but if you want to use a well established code standard there, I recommend using javascript specific selectors in your html. For example, anything you need to grab in JS, use a js- prefixed class name. That way it's really obvious to devs what classes are being used for styling and what classes are being used for javascript.

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
Frontend Mentor logo

Stay up to datewith new challenges, featured solutions, selected articles, and our latest news

Frontend Mentor

  • Unlock Pro
  • Contact us
  • FAQs
  • Become a partner

Explore

  • Learning paths
  • Challenges
  • Solutions
  • Articles

Community

  • Discord
  • Guidelines

For companies

  • Hire developers
  • Train developers
© Frontend Mentor 2019 - 2025
  • Terms
  • Cookie Policy
  • Privacy Policy
  • License

Oops! 😬

You need to be logged in before you can do that.

Log in with GitHub

Oops! 😬

You need to be logged in before you can do that.

Log in with GitHub

How does the accessibility report work?

When a solution is submitted, we use axe-core to run an automated audit of your code.

This picks out common accessibility issues like not using semantic HTML and not having proper heading hierarchies, among others.

This automated audit is fairly surface level, so we encourage to you review the project and code in more detail with accessibility best practices in mind.

How does the CSS report work?

When a solution is submitted, we use stylelint to run an automated check on the CSS code.

We've added some of our own linting rules based on recommended best practices. These rules are prefixed with frontend-mentor/ which you'll see at the top of each issue in the report.

The report will audit all CSS, SCSS and Less files in your repository.

How does the HTML validation report work?

When a solution is submitted, we use html-validate to run an automated check on the HTML code.

The report picks out common HTML issues such as not using headings within section elements and incorrect nesting of elements, among others.

Note that the report can pick up “invalid” attributes, which some frameworks automatically add to the HTML. These attributes are crucial for how the frameworks function, although they’re technically not valid HTML. As such, some projects can show up with many HTML validation errors, which are benign and are a necessary part of the framework.

How does the JavaScript validation report work?

When a solution is submitted, we use eslint to run an automated check on the JavaScript code.

The report picks out common JavaScript issues such as not using semicolons and using var instead of let or const, among others.

The report will audit all JS and JSX files in your repository. We currently do not support Typescript or other frontend frameworks.

Frontend Mentor for Teams

Frontend Mentor for Teams helps companies and schools onboard and train developers through project-based learning. Our industry-standard projects give developers hands-on experience tackling real coding problems, helping them master their craft.

If you work in a company or are a student in a coding school, feel free to share Frontend Mentor for Teams with your manager or instructor, as they may use it to help with your coding education.

Learn more

Oops! 😬

You need to be logged in before you can do that.

Log in with GitHub