Important: The information in this article is over 12 months old, and may be out of date or no longer relevant.
But hey, you're here anyway, so give it a read see if it still applies to you.
When starting out in Vue, coming from jQuery, one thing that I did miss was the jQuery slideUp and slideDown functions. They’re just so convenient, easy and effortless to use, and make for a smoother visual experience rather than just block showing or hiding containers.
The need for this sort of behaviour in Vue led me to find Daniel Diekmeier’s incredibly useful vue-slide-up-down component.
For example, a card based layout that should be collapsible – this is the perfect candidate.
It does exactly what it says on the box: “Like jQuery's slideUp/slideDown, but for Vue!”
Well, that’s exactly what I need!
Integration and implementation was effortless, and allowed for hidden (closed) content to be removed from the path of screen readers and keyboard access.
I happened to be updating a project, so thought I’d do refresh of versions for my NPM packages, and the latest version created an issue: hidden content, while technically invisible to screen readers and non-assistive device users, was still able to be focused via the keyboard. Let’s say you have a button or form element – when closed, I shouldn’t be able to access it, but I could still tab to it.
There was an issue on Github about this – and a workaround – but the workaround seemed like it was making it harder to deliver accessible code for any developer. If using a component, surely the component should do the heavy lifting, rather than relying on all developers to implement that.
Basically, one specific edge case – giving your component a minimum height when closed (so it could be partially visible) was the reason that it was no longer accessible. My argument was that a closed component is just that – closed.
After a few comments back and forth (and in the meantime forking and finding a solution that had better accessibility for screen readers and keyboard-only users), I offered to submit a Pull Request that would address this.
Rather than have the default be inaccessible, the default is delivering better accessibility for screen readers and keyboard users, and if the developer needs a min height, they need to work at disabling the accessibility improvements.
Personal rant aka side note: if you’re needing a min height, maybe wrap the collapsible container with your additional markup to handle this AND make it accessible, rather than compromising the accessibility of the entire component for all developers. But that’s just my two cents.
So I made my pull request on the source of the component, did some updates to the demo page to better showcase behaviours, and has now been accepted and merged in to the main branch. Woo! I believe Daniel will be rolling it out to the next release soon – so it’ll be nice to be able to rely back on the master branch rather than my project-specific fork.
Check out Daniel’s awesome component at: