Design comparison
Solution retrospective
Hey guys,
I haven't submitted anything in a while so I'm happy I could find some time for this. Feels like I've been focusing on different things at work lately (even some backend stuff) so I really enjoyed doing CSS again. ^^
This was a quick and easy challenge, I learned nothing new, I just wanted to have some fun with it and see how rusty my CSS got in the past few months.
Take a look if you want, if you see any mistakes, don't be scared to point them out. Have a good day, peeps! ❤️
Community feedback
- @grace-snowPosted over 1 year ago
This is a really nice solution, well done!
A couple of small notes...
- If you remove list styling some assistive tech will remove the list semantics altogether. An easy way to restore them is to add
role="list"
to the ul/ol androle="listitem"
to each li. - To programmatically link the error message to the input, wrap it in an extra element that is always present in the DOM (not display none) and give it an ID. Then use aria-describedby on the input pointing to the ID. If you don't want to wrap it in an extra element, you can use the existing ID and remove the hidden/display none from the existing error element. But the text inside that error element must be empty by default so it doesn't get read out.
- Focus-visible styles need to be really obvious so that keyboard users know where they are on the page. In fact this autumn, the new WCAG requirements will add success criteria to make it clearer what is required. A pale dotted outline is fine for a focus style, but not for a focus**-visible** style. It doesn't need to look pretty, it needs to look bold/obvious/clear
- Consider adding an aria-live attribute to this whole component. That way any DOM changes will be announced to screenreaders immediately on change (e.g. the error messages and when the content changes between thank you / form)
- I recommend managing focus on this. Currently, if you submit the form or dismiss the confirmation, focus moves to the body instead of the new content. Instead, you could give the two headings a negative tabindex and move focus onto whichever of them is present on button click/form submit. This may negate the need for point 4 in this feedback (although you'd still need to ensure the error has aria-live so that gets read out)
I hope all this makes sense and is helpful. This really is a very good solution.
Marked as helpful1@FluffyKasPosted over 1 year ago@grace-snow
Hey Grace, I appreciate the time you took to check out my solution! I try to pay attention to accessibility and learn more about it, but I rarely get feedback on this. Unfortunately, at work we just don't really care about it... So yeah, your comment was very helpful! ^^ I made the changes, I hope now it's better and I'll read a bit about the things you mentioned above. Thanks again.
2 - If you remove list styling some assistive tech will remove the list semantics altogether. An easy way to restore them is to add
- @OmprakashRPosted over 1 year ago
Hi, Congratulations!
I have some suggestions for this task.
-
add bullet li images
ul { list-style-image: url('sqpurple.gif'); }
orli::before { background-image: url("image_URL"); }
With this approach no need to add images again and again. -
add an
alt
attribute in the image tag, and add the width and height for best accessibility
I hope this is helpful for you!
Thank You!!!
Marked as helpful1@FluffyKasPosted over 1 year ago@OmprakashR
Hiyo, thanks a lot for looking at it! ^^
For decorative images you can just have their alt texts empty but thank you for the tip on the list item images! I haven't thought of doing that, I'm going to try it ^^
0@OmprakashRPosted over 1 year ago@FluffyKas welcome.
- Yes, but if you add any relevant text in
alt
that helps the user to understand what exactly comes in that place when the network is low or the website does not render properly, or broken image.
0@FluffyKasPosted over 1 year ago@OmprakashR
Well, I suppose that's somewhat up to your own preference, but personally, as a user I wouldn't find it very helpful if instead of the broken image I'd see an alt text of, let's say, "checkmark icon" (in a sense that I'm not missing out on context if I don't see that alt text). And as a developer, I would rather spare people using screen readers of having to listen to checkmark icon alt texts being announced >.< But as I said, this is most likely a matter of personal taste too.
2@OmprakashRPosted over 1 year ago@FluffyKas .
Yes, you are right. but it gives an idea to the user is the broken image regarding which context, as you mention screen readers having to listen for this is also important.
0@FluffyKasPosted over 1 year ago@OmprakashR
Oh, I do write alt texts when they are essential and they add something to the context. It's not that I'm forgetting about them. But no, I don't think a person not seeing the screen benefits at all from purely knowing there is a broken image somewhere on the website that doesn't have to do anything with the context, it doesn't help them to interact with the page, etc. Just think about it, what happens if a broken image doesn't get announced? Nothing happens, and that's my point actually. They don't miss out on anything, they don't lose out on the context.
I do realise some developers are adamant on giving non-important icons alt texts as well, I just don't think this is really correct (although yeah, not harmful either just annoying at worst). I leave the WAI tutorial on alt texts for reference.
1 -
- @ramazanyamacPosted over 1 year ago
You can use grid for layout. Guide => https://css-tricks.com/snippets/css/complete-guide-grid/
0 - @mattstuddertPosted over 1 year ago
Nice to see you posting a new solution, @FluffyKas! 🥳 That's interesting you've been focusing more on back-end stuff lately. How have you found the switch to more full-stack development?
0@FluffyKasPosted over 1 year ago@mattstuddert Hey Matt, to my surprise it's been great actually! Backend used to be something intimidating for me, then I got thrown into really deep water with Laravel at work. Since then I got a bit more comfortable and overall it really helped me to get better at frontend dev too. It's nice to understand it a bit more how these things connect. A year ago I thought writing an API is some otherworldly thing, so yeah... long way to go, but I'm happy with how much I'm learning. 😊
0@mattstuddertPosted over 1 year ago@FluffyKas, that's awesome to hear! Never worked with Laravel before, but it seems like a solid framework. Always nice to pick up new technologies and skills. As you said, they also have a funny way of improving how you think about everything you already know!
0
Please log in to post a comment
Log in with GitHubJoin 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