Newsletter Signup Page

Community feedback

• 

  T

  Grace•31,830

  @grace-snowPosted over 1 year ago

  This is a really nice solution, well done!

  A couple of small notes...

  1. 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 and role="listitem" to each li.
  2. 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.
  3. 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
  4. 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)
  5. 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 helpful

  1

  ---

  

  P

  Fluffy Kas•7,695

  @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
• 

  Omprakash Rahangdale•900

  @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'); } or li::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 helpful

  1

  ---

  

  P

  Fluffy Kas•7,695

  @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

  

  Omprakash Rahangdale•900

  @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

  

  P

  Fluffy Kas•7,695

  @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

  

  Omprakash Rahangdale•900

  @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

  

  P

  Fluffy Kas•7,695

  @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

  

  Omprakash Rahangdale•900

  @OmprakashRPosted over 1 year ago

  @FluffyKas Thank you for the article 😊

  0
• 

  Ramazan Yamac•[object Object]

  @ramazanyamacPosted over 1 year ago

  You can use grid for layout. Guide => https://css-tricks.com/snippets/css/complete-guide-grid/

  0
• 

  webdevcodi•[object Object]

  @desiredstate2021Posted over 1 year ago

  Dope solution.

  0
• 

  T

  Matt Studdert•13,611

  @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

  ---

  

  P

  Fluffy Kas•7,695

  @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

  

  T

  Matt Studdert•13,611

  @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