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

Mobile-first Order Summary Component Using HTML, Scss, Flexbox

accessibility, bem, sass/scss
Kingsley Agu•285
@didyouseekyng
A solution to the Order summary component challenge
View live sitePreview (opens in new tab)View codeCode (opens in new tab)

Solution retrospective


I finished this project today and I tried to correct certain mistakes I made on my last solution regarding accessibility. I had to do the #nomouse challenge working around the Order Summary with just the keyboard. I also added label elements with screen-reader users in mind. I'm trying to fine tune my consciousness on writing code that is accessible to different users. Please feel free to run through my code. I'm open to receiving positive feedback. Thanks!

Code
Select a file

Please log in to post a comment

Log in with GitHub

Community feedback

  • Vanza Setia•27,715
    @vanzasetia
    Posted about 3 years ago

    Hi there! 👋

    You've got a lot of feedback from some people. So, I'm just going to give one or two pieces of feedback on this solution.

    • Firstly, I suggest using rem for font-size. It's important to make sure that it scales properly when the users change their default font size setting.
    • Secondly, I agree with @FluffyKas that only use aria-label if there's no visible text like icon buttons (e.g. Twitter "love" button, etc).

    Anyway, I decided to create a page where there's visible link text and aria-label. I tested it with Narrator in the Chrome browser, and here's the result.

    • Once the page is loaded, Narrator reads the visible text and ignores the aria-label.
    • After I tab (focus) to the link, Narrator reads the aria-label and ignores the visible text.
    • By the way, here's the HTML markup that I tested.
    <a href="/" aria-label="screen reader please read me">I just read the visible text</a>
    

    I suggest you to read this article by Josh Comeau about pixels and rems units. It's an amazing article that will tell you when to use px and when to use rem.

    So, that's it! Hope it's useful and sorry for the late reply. 😅

    Marked as helpful
  • Kamasah-Dickson•5,570
    @Kamasah-Dickson
    Posted about 3 years ago

    Your solution looks great on small mobile . To help you with the accessibility issue, wrap your card in a <main> semantic tag or you can just change the parent div of your card into main. Besides good job there👍 Happy coding💻

    Marked as helpful
  • Fluffy Kas•7,655
    @FluffyKas
    Posted about 3 years ago

    Heyo,

    Overall this looks really good, well done! You got some advice already from others on how you could improve but since you tagged me, I try to add something useful too :)

    1. Add aria-labels to elements with no visible text. These links (change, proceed to payment, cancel order) has some text content already, so by adding aria-labels the same text will be just announced twice by screen readers.

    2. It would be a better idea to center your component using grid/flexbox, it's more reliable than adding margins to it.

    3. You could add some transitions to the links, so their hover state looks a bit smoother!

    4. For me, that font-size: .6875rem looks way too small for the Change link, perhaps it could be a tiny bit bigger.

    Also, if I understand right, you were aiming to make this component keyboard-compatible? What did you add exactly? I tried navigating through it only with my keyboard (also checked the css, to be sure) and I don't see anything but the default browser focus (which btw is really barely visible with the color-theme of this challenge, so I suggest adding some custom focus to it.)

    Marked as helpful
  • Abdul•8,560
    @Samadeen
    Posted about 3 years ago

    Hey!! Cheers 🥂 on completing this challenge.. .

    Here are my suggestions..

    • You can wrap your attribution section in a footer tag to avoid accessibility issues.
    • You should add some margin-top to your container to push it down a little

    This should fix most of your accessibility issues

    . Regardless you did amazing... hope you find this helpful... Happy coding!!!

    Marked as helpful
  • Danilo Blas•6,300
    @Sdann26
    Posted about 3 years ago

    I would tell you to note that the words "Order Summary" and "Annual plan" have a different color, which you should change. If I am not mistaken it is this color which they have: color: hsl(223, 47%, 23%).

    Marked as helpful
  • Kingsley Agu•285
    @didyouseekyng
    Posted about 3 years ago

    @samadeen, @Sdann26, @vanzasetia, @Kamasah-Dickson, @FluffyKas, @grace-snow

    I know you might be busy with certain things but I would appreciate it if out of your busy schedule you run through my code and help me identify areas I need to strengthen.

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

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

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