Skip to content
  • Unlock Pro
  • Log in with GitHub
Solution
Submitted almost 3 years ago

An interactive rating component developed with vanilla JavaScript

accessibility, webpack
dannxvc•180
@dannxvc
A solution to the Interactive rating component challenge
View live sitePreview (opens in new tab)View codeCode (opens in new tab)

Solution retrospective


Hi! I just developed this interactive rating component with vanilla JavaScript, and I learnt a lot about accessibility, I read some articles related to this so I decided to use radio buttons for the options and I used css without losing accessibility. This article helped me through this, and I hope it can help more people as well.

I appreciate any feedback about my code. Thank you.

Code
Select a file

Please log in to post a comment

Log in with GitHub

Community feedback

  • CyrusKabir•1,885
    @CyrusKabir
    Posted almost 3 years ago

    Hi @dannxvc, you did a good job on this challenge. your card have some problems both in code and accessibility.

    1.Accessibility: at first I just try to test accessibility with just tab key and I didn't know for radio groups we should use tab + arrow keys. one hidden and weird bug is when some one want select rating number 1 at first with just keyboard it's hard I mean first tab key just can select our radio groups then we should iterate with arrow keys and if some one hit tab key at first for rating number 1 and then hit enter in thank you card there is no rating selected

    2.CSS: you have some duplicates code in rating buttons implementing. like adding pseudo elements to label for just creating hover effects and for button itself. you can do all of them in label itself. one another duplicates is two different rules for .options label and both of them have position: relative. I changed some duplicated codes and here is the result :

    .options input[type="radio"] {
        opacity: 0;
        position: absolute;
    }
    .options input[type="radio"]:checked + label {
        background-color: var(--primary);
    }
    .options input[type="radio"]:checked + label span,
    .options input[type="radio"]:focus + label span{
        color: var(--white);
    }
    .options input[type="radio"]:focus + label{
        outline: rgb(59, 153, 252) auto 5px;
    }
    
    .options label:nth-of-type(1){
        margin-left: 0;
    }
    
    .options label:hover{
        transition: .3s ease-in-out;
        background-color: var(--gray);
        color: var(--white);
    }
    
    .options label{
        position: relative;
        display: inline-block;
        height:  3rem;
        width:  3rem;
        background: var(--blue-light);
        border-radius: 50%;  
        padding: 0.5rem;
        cursor: pointer;
        justify-content: center;
        margin-left: 1rem;
    }
    
    span{
        position: absolute;
        top: 50%;
        left: 50%;
        transform: translate(-50%, -50%);
        z-index: 1;
        color: inherit;
        font-size: 0.8rem;
    }
    

    I still haven't found a solution for accessibility problem. but at all you did good job on having good accessibility with those radio buttons also I learned about how we should interact with radio buttons with keyboard. hope I could help you. good luck. ☻

    Marked as helpful
  • Ayoub Ahabchane•290
    @ayouchane
    Posted almost 3 years ago

    I like that you chose to mark it up it as a form. That makes a lot of sense actually. It was my initial intention, but then I gave up on it and went for a list instead because I wasn't sure how much time the trial and error process is gonna take me had I went down that path, especially when it comes to overriding the styling of native browser element. But Now I can look at the implementation of someone who actually took the time to do it so thank you! And you got the design on lock too, awesome work!

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.

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