Accessibility First DevRel. I focus on ensuring content created, events held and company assets are as accessible as possible, for as many people as possible.
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 with role="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=true will 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 use display: none on 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.
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…
Accessibility First DevRel. I focus on ensuring content created, events held and company assets are as accessible as possible, for as many people as possible.
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.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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. 😁
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 😉
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.