Recently, I found myself craving to make something interesting. So I sat down and scrolled through dribbble to see if there was anything on there t...
For further actions, you may consider blocking this person and/or reporting abuse
Unfortunately this pattern won't work (make that doesn't work, I did give it a quick try) properly with a screen reader.
It breaks the ability to open the buttons once a screen reader is involved due to how the click handler behaves.
Also you will never get the "expanded" state announced as it is not valid on a
<div>, you could possibly remedy this withrole="button"on the<div>but then you have a big issue with nested buttons.In fact nested interactive elements is something that should be avoided as it can cause havoc with click handlers once a screen reader gets involved.
The other issue is that
aria-hidden=truewill not hide focusable / interactive elements.As such when you focus the top panel in a screen reader it still reads out the two buttons (on number 2). You can fix this by adding
tabindex="-1"to the buttons when the front section is closed as this removes the items from the focus order (or just usedisplay: noneon the buttons until such time as the front cover is moved slightly, which would be preferable).One last minor point, visible text rather than a title would be great on the buttons for people who can't associate abstract iconography with actions.
How to fix it?
One suggestion on how to fix these issues would be to restructure the HTML so it looks more like an accordion (in the HTML I mean) and then use absolute positioning or a similar technique to position the draggable top section on top of the button holder.
So your button (as you could now make the front card an actual
<button>) would open the hidden section which is a sibling of the button.It might take a little bit of JS trickery to handle touch start and (if you think a mouse slide action is better than a click) the mouse position movement but for screen readers and keyboard only users the behaviour would be much better.
Sorry I can't find any quick fixes with this one 😞 but the nested structure is where the issue lies.
Despite all of that I love the design, and obviously it is still very much worthy of a ❤ and a 🦄! 😁
p.s. I gave an answer on Stack Overflow that you could use the principle from that was about a button on top of another button where they appeared to be nested. Not sure if it is useful or not but I thought I would include it just in case.
Preword
Don't nest interactive elements
There is a reason that it isn't valid HTML to nest buttons or hyperlinks, it causes nightmares for knowing which action should be performed on a click (for a start) and for assistive technology this makes things even worse as it can confuse the accessibility…
I had hoped you'd leave a comment, thank you!
I've update my structure slightly and now the screen reader is reading out the collapsed state correctly. 😁
I only got a chance to view on my phone so couldn't fully test accessibility, I'm no expert either but have worked with accessibility agencies on some projects.
Just some quick notes, you don't want the title attribute and the aria-label at the same time, this can confuse some screen readers. Also I wouldn't suggest an h4 tag, assuming this is to be used on page along with other components it's unlikely that it would line up with an h4, if these arent to be headings I would consider a different tag, comes to mind but maybe there is a better choice yet
Glad to see you taking the initiative to test your skills while making accessibility a focus, not many bother to do much here so great job!
I've updated the h4 to another styled span. I can't see anything that says not to use a title though, it appears most screen readers ignore titles by default, and others don't support it at all.
Not many people hope I come along and write a massive list of things to tackle 😜🤣
At a glance on my phone it looks way better, if I get chance tomorrow I will have a look on PC!
If you get the pattern right I’m stealing it as I like the design so it isn’t anything other than selfishness 😉
This is UX so bad it is worthy of being included in one of Google's web apps.
Oh, what's wrong with the UX?
That's only the UX, I didn't take a close look at the code, but a quick look reveals the implementation uses events to change classes/css, which is really bad.
Ok, I'm not sure I agree with any of those points to be honest 😅
Though I do want to ask about why you say using "events to change classes/css" is "really bad"? It's the first time I've heard someone say this is bad.
How? If you have to make excuses for your libraries in your UI, you picked the wrong library.
That doesn't show on my screen.
Your example requires a double click.
They don't have any meaning to a user that is using the card nor the developer selecting which colors they should be. Actually it's worse, the color and display is almost 100% the toast display from bootstrap which indicates the "level" of the message.
That's irrelevant and doesn't make it good UI.
Cards are frequently discouraged in most frameworks, UX designs, so requiring their use is frequently problematic.
Writing JS to do something that css can do natively is an indication of lack of css knowledge. It's also way slower and requires management of unnecessary JS resources which provides another area where it's easy to get it wrong.
Hope that helps.
Which browser are you using? The cursor and drag work fine for me on mobile and on desktop in chrome, Firefox and edge?
What am I doing in JS that CSS can do natively?