Building accessible-app.com: Hello, Vue implementation
Caution! This article was published over a year ago, and hasn't been updated since. Situation, software and support of the topic below could have changed in the meantime.
This is going to be a rather short blog but link heavy post. Finally leaving the phase of mere writing about inclusivity of web apps (and maybe supplying a code example here and there), now entering the time where I finally put things together in the browser and build the example app, now dubbed "Accessibooks".
As stated in the last article, I started with Vue and you can find the unspectacular beginnings here: vuejs.accessible-app.com. The source code is available on GitHub.
This is part 7 of an article series on building "accessible-app.com".
Read the other posts:
- Very first steps
- Further steps together
- A specific app idea
- Project status, side benefits, and Routes
- Let's start building
- Dialogs and Modals
- Hello, Vue implementation
- Menu Buttons
- New menu button for Accessibook's shopping cart
- Accessible Animations
- The shopping cart and aria-live regions
The current state of the VueJS implementation of #accessibleapp
What's currently implemented
At it's core, this first implementation is a basic HTML structure, including:
- a
<header>
landmark, accompanied with the role ofbanner
, (for backwards compatibility reasons) - a
<main>
landmark, accompanied with the role ofmain
, (for backwards compatibility reasons) - a
<footer>
landmark, accompanied with the role of contentinfo, (also for backwards compatibility reasons) - a
<nav>
landmark for the main navigation with a label (if you use multiple landmarks of the same type – and I plan to – it is best practice to give then an accessible name)
At the styling front the design is very simple and has sufficient color contrasts. Beyond that you can find explicit focus styles on every interactive element (and, as part of showcasing the accessible routing solution you can even turn on a stronger focus indicator that works on non-interactive elements).
Lastly, I implemented modal windows, which currently work as a demonstration how to implement them accessibly (see: Modal and non-modal dialogs - and Vue) and to harbour error messages when you interact with yet unfinished components.
Learnings
While building I stumbled upon a few things:
- Using vue-portal: If you want to use the same
<portal-target />
for several modal dialogs you have to add themultiple
attribute - Using the accessible routing strategy: The main navigation should indicate programmatically which "page" or route is currently active and there is an ARIA attribute for that,
aria-current
. Unfortunately, vue-router's<route-link />
does not support setting attributes on the route links (but will add this functionality in a future version). Currently only the class ofrouter-link-exact-active
indicates the current route. But at least this gave my a basis to write a quick workaround to setaria-current="page"
after successful route transition. - A further best practice after route change is to change the document's title. I added this in my article on accessible routing with vue.js, and also in the example CodePen. But it is important enough to be mentioned here once again. Here is how I solved it (the data itself is stored here).
Next steps
I plan to target the menu buttons next (see the assigned GitHub issue in Accessible App's backlog). But I am, in parallel, always open for feedback on the current state of vuejs.accessible-app.com. And if anyone wants to start with the React or Angular implementation - go for it!