Blog: JS

vue-slide-up-down: helping improve accessibility


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.

Not good.

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:


View all

Deleting data: soft, hard or audit?

For years I have developed web apps with the idea of soft deletes: when data is deleted, it is simply marked as “deleted”, but not actually deleted from the...

Continue reading...


Restructuring my SPA and why I kept my CRUD calls out of Vuex

I love working with Vue – and have used it numerous times for easily adding components to existing sites, including fetching data from APIs, and now am building...

Continue reading...


Choosing the best content management system (CMS)

This article was written for and originally appeared on Blueprint by Tiny. If you ask a web developer what the “best” content management system (CMS) is,...

Continue reading...


The Last of Us: Remastered

I know, I’m late to the party. Really late. But better late than never, right? Early in the PS4’s life, The Last of Us Remastered came out, and I was looking...

Continue reading...

I am the Development Director (and co-owner) at Mity Digital, a Melbourne-based digital agency specialising in responsive web design, custom web development and graphic design.
Mity Digital