DEV Community: Marcus Herrmann

Accessible Overflow

Marcus Herrmann — Thu, 08 Jul 2021 05:49:43 +0000

One major tenet of web accessibility is that users have various strategies to operate your website. While still too many web developers aren't able to name input modes beyond pointer devices (mouse and touch), properly covering keyboard accessibility will get you the most bang for your buck. If you ensure that all the features of your site can be operated with a defined collection of keys (tab key, space bar, enter key, arrow keys, etc) you largely increased the likelihood that people with all kinds of strategies and assistive technologies are able to use the site you built.

Rock'n'Scroll

"Navigating a website" can, of course, mean jumping from interactive control to interactive control but most forms of interactions come down to reading or passively experiencing your content. A central way to do that is of course scrolling. It's obvious that mouse owners can use the scrollbar or a particular mouse wheel and touch users drag the site up or down. But I think the strategy keyboard-only users employ for scrolling is known far beyond this user group: using your keyboard's arrow keys (or is it just me, especially when reading long texts on the Desktop?).

Anyway, arrow keys scroll the overall website, regardless of the focus's precise position, and sometimes, this is all you need. But what about particular containers that harbour content that is either horizontally or vertically too large for its parent? It is allowed to overflow, more often than not with the CSS overflow: auto. Alas, the situation around keyboard accessibility of these containers is patchy, and I only completly realized this after a current customer project which had an overflowing container. So, what follows is my little research on the topic and the current state of overflow scrolling afairs (see original sources at the bottom of the article).

Overflow and Focus

Firefox, for example, puts an overflowing container into the tab order, making it reachable and its content scrollable. Because it has no focus styles, it is not really obvious that it has focus, though, but web developers can at least write a CSS selector like .my-overflowing-div:focus to make its state more clear to friends of the Mozilla. However, the situation in Chrome, Chrome-based Edge and Safari is different. Without any changes in the HTML, overflowing content is not scrollable with the keyboard (unless, of course, there is an interactive element inside the container - but this scrolling doesn't uncover every part of the container).

All interactive should be focusable
(Using WAI-ARIA)

Ensuring a coherent experience across browsers

The Webkit and Blink team are aware of this topic insofar that issues related to that exist for 3 or 5 years, respectively (Webkit Issue # 585413 and Chrome's one even is on "Intent to ship" since 2.5 years). Unfortunately, there is nothing tangible beside the tickets, so web developers must apply a hack if they want to convey Firefox's behaviour to all browsers. This workaround, or "hack" as Adrian Roselli calls it, comes from Steve Faulkner and consists of three steps:

Add tabindex="0" to the overflowing container to make it baseline keyboard accessible.
Show this keyboard accessibility to users by applying custom focus styles: .my-owerflowing-div:focus { outline: 2px solid; } (if you want to be both future-proof when it comes to WCAG and an overall good web author citizen, take care of focus style contrasts).
"Promote" the <div> to a landmark region by both applying role="region" and supplying an accessible name, by using aria-label, for example. By doing so, you provide much-needed context to screen reader users - because they suddenly discover a focussable element that is not interactive in the classic sense (like a link or button would be).

Demos and Links

Steve Faulkner provided the code mentioned above combined into a CodePen
More than five years ago, he published Short note on improving usability of scrollable regions
As for every web accessibility topic, Adrian Roselli has a deep dive article: Keyboard and Overflow

Twenty inclusive strategies for building web apps in 2020

Marcus Herrmann — Thu, 19 Dec 2019 08:19:02 +0000

Originally posted on marcus.io.

With the start of the new year, it is a good opportunity to look into the accessibility of your web app. Here are 20 starting points to make your web app more inclusive in 2020.

Covering the basics is 90% of the way of making your web app accessible! Yes, there are special accessibility problems that have to do with how web apps work, but it is valid to say: If you concentrate on the basics of building an inclusive web document you'll take care of the huge majority of web app accessibility problems. And, tackle them first: Because what's the use of sophisticated focus management on route transition for example, when non-visual users can't really find the main navigation in the first place?
Use the power of CSS feature queries like prefers-reduced-motion, and additionally offer the setting to disable animations. For some people, animations on the web can not only be annoying but actually harmful (see A11yProject's "Understanding vestibular disorders"). Fortunately, these users can now enable a setting in their operating system that they opt out of potential seizure triggering animations, and us developers can detect this setting. But regardless of the OS's ability to submit a prefers-reduced-motion preference: Use the power of your web app's state to implement a setting like this (here's an example how you could do this in Vue.js). A good real-life example is the new twitter web app.
Test your apps loading/interstitial states with screen readers. A frequent feature of a web-app is to load data asynchronously, e.g. from an internal or external API or database. This leads to loading states that you, I assume, convey visually with nicely animated progress bars. But I invite you to check your app, and especially these in-between states with a screen reader: Is it clear what happens or does the screen reader just stays silent for an indeterminate amount of time? If so, I'd suggest you inform yourself if ARIA live regions can help (read the "accessible notifications" pattern on Accessible App)
Add axe core, pa11y-ci, tenon-cli or the like to your tooling/tests infrastructure. With most web app comes a complex tooling setup in order to a development server, build your app and run tests. While this makes web app development rather complex, it gives you the opportunity to write and run tests, especially for accessibility. Note: only about 20-30% of accessibility issues are testable automatically, and there are sometimes false negatives – but in overall, having accessibility-related test coverage does no harm, especially when it comes to educating other team members working on the same project.
Make sure that your whole app, especially the custom elements, are keyboard accessible. Keyboard accessibility is crucial to inclusive interface design. Many developers are not aware of the multitude of possibilities and strategies people have to use websites – and in that regard, how important keyboard accessibility really is. When speaking about custom elements, and first, make sure that this particular form of input really cannot be solved with a native input element (since it offers extraordinary amounts of inbuilt accessibility features). If this isn't feasible, take a look into the WAI-ARIA Authoring Practices (but also read the next item of this list).
Be aware that WAI-ARIA Authoring Practices (AP) aren't gospel or standards. When you first stumble upon the authoring practices of W3C's Web Accessibility Initiative, and you care about the inclusive web, you possibly sigh in relief. "Finally", you may think, "a resource how to build accessible custom controls with modern JavaScript and ARIA." While this is true in part - the authoring practices show how ARIA should be used, have in mind that some AP are disputed: Because of the concepts, because of an accidental exclusion of other users, or because of inconsistencies in assistive technologies. As a general rule of thumb, look into the discussions in the Authoring Practices Github issues and see if there is a discussion around the practice you are aiming to implement.
Check your framework for accessibility documentation. Some of the major JavaScript frameworks helping you to build web applications have a whole section on inclusivity in their official documentation (React, for example). Study these resources thoroughly. There may be some gems hidden stating how you can implement accessible solutions in this particular framework with its feature and strengths. Also, if your favourite framework not yet has such a section in its official docs, but you are an accessibility specialist (or have some track record in another framework), think of contributing (and adapting) what you have learned so far. After all, it is open source.
Follow "accessibility people" of your framework. By circumstance, or by design (?), oftentimes people very involved in communities surface as "thought leaders", or at least "representatives" of certain sub-topics in your framework of choice. I bet there are people specialising in accessibility and worth following (e.g. on social media, or via their blog RSS-feed) in every framework. Do just that, keep up to date with your libraries' features that possibly could help everyone implementing accessibility with it.
Check clickable elements outside of forms – are they links or buttons? In modern JavaScript, it is so easy to make elements clickable (actually, it was easy in un-modern JavaScript before, cough onClick attribute, cough). But in accessibility terms, a (let's say) clickable does not make any sense and is actually harmful. There are many good articles out there explaining this over and over (like this article from Karl Groves), so I'm not trying to add another piece of content. Rather, I'd like to emphasize that is important to know when to use a link (generally speaking: for changes of location in your app) and when to use a button (generally speaking: to change the state of your app or to hide/show things). Marcy Sutton's talk "The Links vs. Buttons Showdown" is a great resource on this.
Check if infinite scroll could be solved more accessible. Infinite scrolling, or virtual scrolling, is both very common in apps (think of: Twitter's ever-changing, self-updating and never-ending timeline) but also a very common accessibility problem. And while role="feed" informs screen reader users of a widget's dynamic and updating nature, infinite feeds are still a problem for other groups, for example keyboard-only, switch device or speech recognition users. I recommend checking Raghavendra Satish Peri's article "Infinite Scrolling & Role=Feed Accessibility Issues" – and also his suggestion to solve most of the problems, and whether this is a good fit for your projects that have infinitely scrolling parts.
If your web app enables people to create content – check if you can help them make it more accessible. Now, this is a topic that can't be summarized in a paragraph, since features for content creating come in different shapes and sizes. But the important bits are: make sure that both user-generated content and the way to user-generated content is accessible. And that there is ~~an app~~ a standard for that: The Authoring Tools Accessibility Guidelines
Check if it uses just the right amount of ARIA. For some people WAI-ARIA is the solution for all accessibility problems, adds functionality just by using it or see it as some form of miracle worker. Just add it to your web-app, and it will automagically make it more accessible. Alas, that could not be further from the truth. In reality, ARIA is a specification especially for assistive technology and in some regards, "a polyfill HTML". It helps developers to build or retrofit custom widgets in a way that screen-reader, for example, have the chance to understand them. First and foremost, WAI-ARIA is a contract with the user about adhering to certain usage patterns and to advertise that certain keyboard usage patterns are implemented. I think this general misunderstanding leads to findings like the analysis of the WebAim Million that uncovered that the more ARIA is used, the less accessible one website is. Or, as Bruce Lawson puts it: "...unless you really really know what you're doing, it's easy to make things worse with ARIA." So why the WebAim Million result is the way it is, is not hard to imagine, having this central misunderstanding in mind. Don't fall into this trap when building your web app!
Test your app with people with disabilities! Adhering to standards, being dogmatic and building things academically correct is just one part of the puzzle (alas, this aspect alone is often neglected). The other essential part is to talk with your users, test our assumptions and – ideally – ask people with disabilities in order to find out if your app (or any digital project in that regards) is really **built in an inclusive way.
If you want to use a web UI framework, check its accessibility. Sometimes is recreating everything from scratch is not the most economical option for your project and you reach out for established web UI frameworks like Foundation, Bootstrap, Material UI or Uikit. But bear in mind that it is important to have an idea of how accessible that UI framework actually is, and if it helps or hinders you when making your app more accessible. For help with that, research what's written about the accessibility of your chosen framework, or read articles like "The state of accessible web UI frameworks" from Derek Kay, who used a methodical approach in reviewing 20+ UI frameworks in regards to their accessibility features.
Keep updated regarding the Accessibility Object Model (AOM). The AOM will be an API to allow developers to modify and convey semantics to the accessibility tree, without having to rely on HTML (Reminder: the accessibility tree is a representation for the DOM tree for assistive technologies like screen readers or speech recognition software). To quote Hidde de Vries: "With direct access to accessibility info, we could set accessibility properties without markup, we could create accessibility trees for things that don’t exist in the DOM (like for contents of canvas elements), and testing accessibility may improve." Although both proposals and browser implementations of the Accessibility Object Model are still in "work in progress" state, it is very much worth following its development. To do that I would suggest following publications, tweets and talks from Leonie Watson (Blog, Twitter) and aforementioned Hidde (Blog, Twitter).
Look into the advantages modern JavaScript frameworks can bring. It's not always black and white, especially when it comes to accessibility. Still, frameworks have a bad reputation in that regard. But it is much more exciting to think about how to use their undeniable powers – so to speak – for a good cause. In 2019, a whole bunch of people helped my to collect a list of ideas, resources, keywords and starting points answering the question: "In what ways could React, Vue, Angular and Co and their features actually facilitate inclusive designs?"
InFORM yourself about screen reader's form mode: The big screen readers for Windows operating system, namely NVDA and JAWS have special modes they switch into and offer interaction patterns that match that mode or circumstance. There is the browser mode, the so-called application mode, and something like the form mode. Since web apps predominantly consist of some kind of form input controls or collections of forms, it is well worth to look into the latter. Generally speaking screen reader users in form mode can only navigate to focusable element – and you have to keep this in mind, especially when dealing with input labels, descriptions, errors and their respective programmatic associations. My suggestion to dive into this topic: Accessibility Developer Guide's "Screen reader browse and focus modes".
Check if the usage pattern of your custom components follow established patterns like modal or disclosure. In his book "Apps for All", Heydon Pickering writes: "Looking at JavaScript-driven web interfaces, by far the most common interaction style is based on showing stuff or hiding it or... oh, that’s pretty much it." I invite you to take such a deep look into your interfaces and code – does one control toggle the visibility of another? In this case, it's likely that you have built some form of "disclosure widget". Does another control trigger another containers visibility, and does the container try to render the rest of the interface inactive? Then this could be the "modal" concept. If patterns like these are present in your app, try to analyse the accessibility implications of both.
If your app is not fully client-side rendered, care about progressive enhancement. JavaScript is not always available. Its absence normally leads to single page applications not running at all, but not every web app is fully client rendered. Make sure that all of your content is perceivable and independent from processing through JavaScript. Andy bell uses the example of a disclosure widget to show how robust widgets can be built: https://hankchizljaw.com/wrote/a-progressive-disclosure-component/.
If you learn about your framework by tutorials, be critical and don't just copy and paste. Many tutorial authors are not aware (or don't really care) about accessibility. This is very unfortunate, since video courses a great way of learning for many developers, and learning always starts with imitating and copying (the latter sometimes literally). What often also gets copied is the teacher's missing knowledge or disinterest in the topic of inclusive web developments. Fortunately, this appears to change (highlighting Wes Bos and Adam Wathan here), but it is still way too common. So if you are a beginner in web development (and you happen to read the whole way through this article, which is great in itself! 🎉), be on your guard.

That's it for my – I guess – last blog post of the year. Though I barely scratched the surface on each and every on this topics, I hope the list above gives you new ideas, keywords, or starting points for your learning. With this in mind: May 2020 be the year of improved accessibility on the web!

Fata Morganas in Accessibility

Marcus Herrmann — Mon, 28 Oct 2019 16:36:12 +0000

Originally posted on marcus.io.

Sometimes you stumble over things where your first thoughts are, "Hey, thats great for accessibility!" or "Nice, it's always better to solve things in a browser-native way instead of relying on JavaScript". And this has happened to me before.

Unfortunately, once you dive in deeper in to these, at first, perfect solutions you read more and more about their imperfections or downright disadvantages. Here are some elements, attributes or techniques that initially piqued my interest. But luckily, after that "Using <details>/<summary> for a menu" episode, I decided to do some research before diving into the phase of building demos and excitedly writing about that new shiny a11y thing. Because sometimes these new techniques turn out to be some kind of fata morganas, or solutions that are not yet ready for prime-time.

No. 1: Using `aria-role="feed"` solves accessibility issues for all users

I was happy when I first read about the feed role. To give context: It is meant to help in situations where there is infinite scrolling and a continuous stream of content (like for example Twitter's, Mastodon's or Facebook's status message list). And I wasn't alone. Quote Deque employee Raghavendra Satish Peri:

Just like many developers and the accessibility professionals, I initially believed that role=”feed” would solve any accessibility-related problems for infinite scrolling.

But the disadvantage of relying on role="feed" alone to solve a feed's accessibility problem is that there are more than just screen reader users who are negatively affected by infinite scroll interfaces. Additionally, keyboard-only users, speech regocgnition software users, people using zoom, or switch devices and people with cognitive disabilities also have their problems with this pattern.

Aforementioned Raghavendra Satish Peri wrote an interesting article about the scope of the problem and the potential misunderstanding that comes with this role. Furthermore, he suggest an accessible infinite scroll design pattern, which looks promising and worth a look for everybody who plans to implement a feed of this sort themselves in the future (especially since there's no consensus on the "official" usage example by WAI-ARIA Authoring Practices).

No. 2: Detecting screen readers in CSS with the `speech` media query

If you look at it superficially, @media speech seems to be a way to address screen readers via CSS, and a means to avoid .visibility-hidden classes, for example. On a second, more thorough look you'll notice that there is a discussion ongoing in CSS Working Group (Drafts), regarding its removal.

Because one the one hand, it is not supported in user agents at all and on the other, screen readers use screen media type anyway, the agreement is to add a warning regarding @media speech: it "is for pure-audio UAs, not screen readers". So in the future it could be a way to detect Alexa, Siri or Google Home. In the present, though, it is no method to recognize screen readers.

Bear in mind that even it it would work, it wouldn't be a good idea to use it:

There are more screen reader users than the ones who are 100% blind: Also, people who are partially sighted use these types of software, in addition to people with good eyesight but cognitive issues
You shouldn't aim to detect screen readers for ethical privacy reasons.

No. 3: Using the `<dialog>` element for perfectly accessible modal windows

It's actually quite hard to build an accessible modal dialog, so <dialog> appears like a gift at first. To quote Eric Bailey:

I like what dialog represents. HTML should pave the cowpaths of popular UI patterns. They should especially do this when those patterns come with tricky implementation concerns that developers may fail to consider, especially when those considerations include accessibility.

Additionally most of the time the advice – when it comes to ARIA and JavaScript in general – is: "Don't rebuild element or widgets when there is a native one at hand" (ARIA Rule #1). And while this is true in most cases (like using and styling a <select> instead of trying to re-build one) this advice is out of place when it comes to the <dialog> element.

Admittedly, at first glance the native dialog implementation looks rather good: It is, like Chris Coyer states, "not just a semantic element, it has APIs and special CSS". It brings .show(), .showModal() and .hide() methods (and hitting the ESC key closes it), a new mode for forms, namely method="dialog". This means that in the following example, a button click would close the modal in the same way a button in a "normal" form would submit the form's data:

<form method="dialog"><button>Close</button></form>

Furthermore, <dialog> brings a ::backdrop CSS pseudo to precisely style the often darkening overlay, and it even takes care of focus management (minus implementing a focus trap when a modal is open).

Sounds too good to be true? Well, it kind of is. Part of the reason for that is the well-intended focus algorithm that is built in. Unless there is an autofocus attribute present in the dialog it will focus the first focusable element. But it is not granted that this element will be one of the first items in a dialog. Scott O'Hara paints in his article "Having an open dialog" the picture of a scenario where a dialog contains a long text, for example our most favorite internet texts (legal ones like terms of service). Would the first focusable element be at the end of this long, scrolling text a user would experience that a dialog would start in state where the content is already scrolled. Also, one important thing of dialog is focus management is still missing: the return of focus to the dialog-triggering element once it closes. So developers might think they take care of accessibility by using <dialog> – but in fact need to programmatically fill these gaps.

Aside from these problems Scott discovered some problems with the dialog in various screen reader and browser combinations. He concludes:

tldr; I’m just going to say right now that the dialog element and its polyfill are not suitable for use in production. And it’s been that way since the dialog’s earliest implementation in Chrome, six-ish years ago.

No. 4: Using `aria-label` as a means to describe everything

Maybe you were like me: When I first heard about aria-label, I thought: "Wonderful, a way to send more information to screen Reader (and screen readers only)."

But don't stop at this thought for three reasons:

Firstly, don't go over the top and try to explain the usage of standard HTML controls and standard ARIA widgets. Adrian Roselli has summed it up wonderfully in his article "Stop Giving Control Hints to Screen Readers" a few days ago.
Secondly, you couldn't just apply aria-label on anything. If you aim to add the attribute on static content (minus elements with landmark roles like <nav>) be aware that you open pandora's box and can't rely on consistent screen reader behavior. To learn more, read "What happens with aria-labelledby, aria-label and aria-describedbyon static HTML elements?" by David MacDonald.
Thirdly, if you are using aria-label and a realtime translation service like Google Translate its values won't be translated in every browser (only in Google Chrome at the time of writing). To circumvent this issue, you could use text perceivable for everyone, and, if you want to influence the accessible name of a given element, you could point to it via aria-labelledby .

Using JavaScript framework powers for good

Marcus Herrmann — Mon, 12 Aug 2019 07:26:17 +0000

Originally posted on marcus.io.

Usually, when talking about modern JavaScript frameworks and accessibility, the dominant opinion is "React and company are bad for for the inclusive web". But in my opinion, it is not the frameworks that are to blame – you can write accessible or inaccessible code, just like you would (or wouldn't) in plain, old, toolchain- and component-less HTML. Rather, what leads to inaccessible apps in the end is education and framework ecosystems: First, boot camps and trainings that focus on features, instead of HTML/CSS fundamentals. Secondly, inaccessible code in tutorials and the overall lack of awareness (admittedly, this is also valid for the web platform as a whole).

But this post is not about real or perceived problems of modern JavaScript frameworks – it's about using their strengths, their unique features or architectural approaches for the sake of accessibility. This week I asked on twitter about ideas of how to use frameworks for a good cause, so to speak: In what ways could React, Vue, Angular and Co and their features actually facilitate inclusive designs?

Let's turn the WebApp/React/A11y discussion around: Do you know of examples where framework characteristics, component based architectures, their abilities etc. actually help #a11y, or at least ease building thoughtful and inclusive applications?

There are advantages

I got great replies to that. Here's my try of summarizing, clustering and interpreting the answers:

Developer experience

Make accessible solutions part of the developer experience - that means: make things easy and fun to use. Use the architectural advantage that everything (including helpers or linters for accessibility norms) is just a npm install away.

Externals: usable, internals: accessible

With ideal components, all the accessibility features are taken care of, are battle-tested so to speak – but hidden away in their "engine room". The developer just uses the components interface, so to speak. Or as Hidde de Vries puts it: Separating the components' internals from its usage layer (more in his corresponding blog post "Baking accessibility into components")

Making accessibility hard to circumvent

Make the usage not only a joy but ensure that it's actually an effort to make an implementation inaccessible (David Brunelle's statement via Dan Abranov). He links Starbucks' React pattern library as an example.

Perry Trinier writes that the component-based architecture can help us enforcing accessibility features by setting up related required prop types (e.g. input labels, legend for a fieldset)

Use all of the framework's functionality...

Your framework has features that aim to make your life as a developer easier, for example concepts like mixins in Vue or hooks in React. Marcy Sutton, James Nimlos, and Almero Steyn suggest to use these for managing ARIA states and property values, e.g. for example generated unique IDs for ARIA references (aria-labelledby, aria-describedby, aria-controls et cetera), or explicit labels of your inputs (this concept: <label for="foo">Name:</label><input id="foo" /> – where "foo" would be the generated id).

...and its design approach

In his tweet, @giuseppegurgone mentioned that you could use a framework's declarative nature for you for accessibility features. Guiseppe also wrote a detailed blog post about what he means by this: "Building accessible modals with React".

Automate...

Almero Steyn reminds us: We can let our framework and the fact that we are not only writing markup, but actually are programming help us with your document outline: For example by automating your headline levels with the Heading component of tenon UI (idea by Sophie Albert)

...or use props in a smart way

If you don't want to go full automation, you can still use props to pass the appropriate heading level into you component, as Heydon Pickering wrote in last year's "Managing heading levels in design systems"

Both sides of the (app) story

@accessabilly likes that frameworks offer "the possibility to have (mostly) identical code on server and client at the same time. This offers opportunities for Progressive Enhancement."

Conclusion (for now)

Thanks again to all respondents! All in all these replies a very good starting points for deeper research and frankly speaking really inspiring stuff. And motivating – on the one hand, to dive in deeper into the framework's advanced concepts, but on the other hand, motivating to check all future features for suitability to improve accessibility. So that hopefully in the months and years to come this list of "framework-exclusive accessibility advantages" grows and grows!

What are the accessibility challenges when building web apps?

Marcus Herrmann — Wed, 20 Mar 2019 14:50:59 +0000

A web application is a computer program that runs in your browser. It is hard to expand the general definition further. Wikipedia says:

The general distinction between a dynamic web page of any kind and a "web application" is unclear. Web sites most likely to be referred to as "web applications" are those which have similar functionality to a desktop software application, or to a mobile app.

But regardless of whether it's a dynamic web page or a single page application - modern "app-like" functionality is built with JavaScript (sometimes with a framework) and this JavaScript should work (and be accessible) for everyone.

Maybe you read in the past that JavaScript is bad for accessibility. While it's always good to build digital products with progressive enhancement in mind some web projects simply can not be made accessible without JavaScript.

Now, what are the specific problems that come with JavaScript?

Click targets that are not links

I'll admit that that headline is a simplification. Of course, even on "non-dynamic web pages" there a more click targets than links. Take a submit button or input elements in forms for example.

The reality is, however, that many web pages offer click targets that are only that - click targets. Neither can you reach them or interact with them via keyboard nor use them with assistive technologies such as screen reader or voice input software. And why? Because, often times the code looks something like this

<span @click="someClickHandler">To be or not to be a button</span>

While you can assign a click handler to any element that doesn't mean that you should. What you should do is using the (maybe boring but powerful) <button> element, because:

Buttons are recognized as interactive elements by all user agents - regardless of whether the web document is perceived visually, auditory or else. It's the Swiss army knife of interaction elements on the web, especially when you use <button type="button" /> to clarify you don't want this button to submit any form by accident. If you wanted to "upgrade" your span to a button - but only regarding its perception, not its functionality - you would need to add role="button" (among other things, read on).
Buttons are by default focusable with the keyboard (if you wanted to make our "span button" focusable you would have to add tabindex="0").
Buttons can be activated by click or touch, but also by ENTER or SPACE keystrokes. So no need to register extra event listeners. Adding a listener on click is fine, ENTER or SPACE keystrokes will be relayed.

Web developers love shortcuts and tools that save time - still some of them refrain from using the battery-included element for interactivity, although it could save precious time and lines of code.

But the styling

Maybe the aversion to buttons has to do with their default styling. It differs from browser to browser and from operating system to operating system, and giving them a coherent styling used to be hard. But that is not the case anymore. Just apply:

button {
    -webkit-appearance: none;
    margin: 0;
    padding: 0;
    border: none;
    border-radius: 0;
    font: inherit;
    color: inherit;
    background: none;
}

But I could use a link with href="#" to achieve the same thing

In order to decide whether to use an <a> or <button> ask yourself: does interacting with that element navigate to a new place (including a change of URL), or does it change something on the page you are on (for example: opening a modal dialog, liking a status on a social media platform, adding an item into your online shopping cart).

In case of navigation, use a link. In case of modification, use a button.

Inputs and Controls

A central part of a typical web app is usually to input data - you enter texts, upload files, make selections, check boxes, rearrange things and the like.

Actually, building an inclusive web app means that anyone could do all these things mentioned above - regardless of what technology they use. Be it a visual browser and a mouse, a switch device, a braille reader that makes user perceive your app in a tactile way - or a screen reader that transforms it to an auditory experience.

The creators of the web have built "input primitives" that cover many input cases - and you already know them. While making your app accessible, ask yourself - can I solve my case by using a text input, textarea, select or multi-select, or checkbox? If your answer is - yes, but they should not look "primitive" – be aware that styling them with CSS only has gotten easier and simpler over the last years. Visit sites like wtfforms.com to update your knowledge about what has become possible, if necessary.

But even for the cases an "input primitive" does not suit your needs the web standard creators have you covered – with ARIA (which stands for: Accessible Rich Internet Applications). Regarding input and controls, Wikipedia describes it as follows:

These user interface controls [...] are often not accessible to users with disabilities, especially screen reader users and users who cannot use a mouse or other pointing device. WAI-ARIA allows web pages (or portions of pages) to declare themselves as applications rather than as static documents, by adding role, property, and state information to dynamic web applications.

WAI-ARIA has been around for a while and if you want to look into recommended approaches please check ARIA Authoring Practices, or the skim through its FAQ (Frequently Asked Questions) to give yourself a general overview.

AJAX - Changing and loading things asynchronously

Web apps try to emulate native apps also regarding their reactivity after some user input. Where a "standard" website would load (anew) after an interaction happend (e.g. with a link or submit button) web apps use an approach dubbed AJAX some time ago. Meaning: asynchronously fetching or storing data without triggering a webpage reload.

As a consequence a web app using AJAX feels "snappy", just like its paragon, the native app. Unfortunately this asynchronousity is rather bad for assistive technologies that consume a web document sequentially. Let's take a screen reader - its normal mode is to read the document from top to button (in reality no user uses it this way, but navigates via headline structure, landmarks, links, controls and the like). Given a screen reader user interacts with a button and, as a consequence, something happens in a web app said user has to actively search for what has changed on website.

An example

Imagine an e-commerce site with "shopping cart" functionality - you browse to the site and can put products into your shopping basket. Let's say this process of "putting things into your cart" should feel snappy and is built with AJAX - so that the user is not redirected to their cart every time they put a product in it. So the user finds a product and clicks on the big "Add to cart" button. Subsequently the shopping cart widgets gets updated, maybe increasing a counter badge somewhere - in short: visually abled users can see that their button click lead to the desired result.

Our screen reader user just interacts with the "Add to cart" button - and then nothing obvious happens. Maybe it does, maybe a shopping cart widget somewhere else in the document is now populated - but maybe the interaction did fail. Unless the screen reader user actively searches for a possible change after button click they won't find out what happened. A very annoying and frustrating situation for them.

Solution strategies

Luckily there are two strategies to avoid this annoyance:

Moving focus programmatically after interaction. With a few exceptions focus shouldn't be explicitly moved but be predictable, so this has to be decided on a case to case basis. Often times the following option is better:
Announcing the failure or success of the interaction with an ARIA live region. With live regions web developers can sprinkle a little asynchronousity into the screen reader experience - in the way that they can interrupt the reading in a polite or more assertive way. In our shopping cart example, a polite message that "Product A has been added to your shopping cart" could be the way. The screen readers virtual focus is not affected in any way – read: the user is still on the same spot in the document as before the interaction – but now they know that their button click actually did work. You can learn more about live regions in MDN's detailed documentation of this great functionality that enables users of assistive technologies to have a way better web app experience.

Route changes

There is a very special type of web app: the Single Page Application (SPA). A SPA consists of one single HTML document (hence the name) - anything else is being loaded in an asynchronous way without ever really navigating off of the page. Quote Wikipedia:

[A Single Page application] interacts with the user by dynamically rewriting the current page rather than loading entire new pages from a server. This approach avoids interruption of the user experience between successive pages, making the application behave more like a desktop application.

So SPAs are asynchronous beasts - therefore all the strategies regarding notifying user of client side changes apply - but there is one more peculiarity. Continue quote:

The page does not reload at any point in the process, nor does control transfer to another page, although the location hash or the HTML5 History API can be used to provide the perception and navigability of separate logical pages in the application.

So Single Page Applications emulate changes of locations by modifying the location hash - to that navigating a SPA feels like navigating a "static page", but quicker and without any server configuration. This is called "routing".

And it is actually a topic for accessibility. Remember the e-commerce example from above -a user clicks on a button and is not provided with a response whether something happened after? The situation when it comes to routing is the same: a screen reader user interacts with a (routing) link - and nothing happens; although, in most cases, large parts of the page have changed.

Best practices for accessible routing:

This is one of the rare occasions where moving focus is recommended. Since the topic of accessible routing is rather new and research for a solid best practice is still ongoing - as of now it's unclear where exactly the focus should be sent to:
- To the top of the document? If implemented this user experience would come close to the experience of a "real page load"
- To the "routing container"? This would mean sending the focus to the element whose content has been exchanged.
- To the first sensible headline of the newly loaded content? What is in favor of this approach is that the user lands directly in the requested content
But regardless of the exact focus target - focus management after route transitions should have a certain delay to take loading times into consideration
Also, it is best practice to change the document's title after a route change
Last but not least: When focus management is just not enough to make the inner workings of your Single Page App transparent to your users (for example when external data needs to be fetched before it can be displayed, and focus moved), consider using a live area to inform users that their request was successful but your app needs a little bit more time.

Conclusion

All in all, the specifics of web apps can be summarized in two points:

Be very clear and transparent about the input options of your app. Remember that the visual representation of a user input is not enough. For example: What looks like a button should be a button semantically and not only a span with a click event listener. For edge cases, consult ARIA Authoring Practice (and accessible-app.com, of course).
Be very clear and transparent about the output of your app, especially when it its not accompanied with a full page reload, and especially when the output happened after some user input. Consult WAI ARIA live region documentation for accessible announcements and visit accessible-app.com once in a while to learn more about emerging best practices (and ready-made framework solutions) regarding accessible routing.

Accessible animations with Vue

Marcus Herrmann — Fri, 01 Mar 2019 16:53:05 +0000

To make the user experience pleasant and - above all - more app-like web-app authors use not only the strategy of asynchronous loading data but also animation. While the user experience of your app could benefit from it (see: "How Functional Animation Helps Improve User Experience") sudden movements could cause, for example, dizziness, vertigo or nausea for some of your users suffering from a motion sensitivity such as vestibular disorders:

Imagine a world where your internal gyroscope is not working properly. Very similar to being intoxicated, things seem to move of their own accord, your feet never quite seem to be stable underneath you, and your senses are moving faster or slower than the rest of syour body.

Source: A11y Project's A primer to vestibular disorders

Luckily there is a new CSS media query (which gains traction regarding browser suppport): prefers-reduced-motion. For example in Apple's MacOS and iOS user can enable this setting on an operating system level (System Settings - Accessibility - Display) - which let CSS authors detect this user preference:

@media (prefers-reduced-motion: reduce) {
    /* Disable animation on your selectors here */
}

But to create an accessible experience in your app even to users are using a OS that does not offer this setting, web app authors should use the pwoer of their material: managing state. You could establish a setting regarding animations in your app that mimics prefers-reduced-motion and could be applied to our app's <body> element. So, if set to true, and therefore present on the body element the following selector would work:

body.user-prefers-reduced-motion-reduce {
    /* Disable animation on your selectors here */
}

I have implemented both described ways and means in https://vuejs.accessible-app.com. If you are on a Mac and want to it out, head to your OS's System Settings and set the "Reduce motion" checkbox. If you happen to use a system without a setting like this you can go to the settings page inside the app: Click the Account button, then go to "My settings". Over there you will find - not very much, actually - but a checkbox labelled "Disable animations". Code-wise checking it adds .user-prefers-reduced-motion-reduce to the body.

Now that we know about activation let's look into the way of actually disabling animations, and it's straight-forward:

@media (prefers-reduced-motion: reduce) {

  * {
    animation: none !important;
    -webkit-animation: none !important;
  }
}

.user-prefers-reduced-motion-reduce {

  * {
    animation: none !important;
    -webkit-animation: none !important;
  }
}

My "Accessibook" example app uses animations rather lightly:

Once a modal window is opened
Once you click on one of the menu buttons (Shopping Cart, Account)

But with either .user-prefers-reduced-motion-reduce or prefers-reduced-motion: reduce set you will see that these animations disappear. I admit, disabling these animations isn't the most compelling example - but hopefully I get the idea across. An idea that one as a web app author should take note of "user queries" like prefers-reduced-motion and that you should offer a choice regarding your animations - independently from this media query's dissemination.

If you want to look into the exact code of the Vuejs implementation of Accessibooks:

Using summary/details as a menu

Marcus Herrmann — Thu, 28 Feb 2019 06:33:02 +0000

My original intention for the next article of the #accessibleapp project was to look at "notifying users of changes", especially regarding content reloads that do not trigger a full page reload (that lack of a full page reload in Single Page Apps leads to the necessity to come up with a routing strategy). Putting an item into a shopping cart in an e-commerce context without redirecting to a proper shopping cart page can be such an asynchronous change of content, and could be hard to notice for, e.g., screen reader users. Leonie Watson writes about this problem:

The update is easy to see at a glance, but not at all easy with a screen reader. First you have to discover that something has changed, then you have to find out where it happened. Even once you know this, you still need to move focus back and forth between the summary and the product information, every time you add an item to the basket.

And at the same time she points to a solution strategy: Using aria-live regions to announce changes on the site or in the app that happened without proper page reload. So, I thought, the next thing to add to my accessible example app "Accessibooks" is shopping cart functionality - it's a fake shopping app after all. While building the feature it turned out that I touch on other accessibility topics, and each one of them is worth their own blog post:

Animations, and how to turn them off via setting within the app, or inside your operating system
Aforementioned use of aria-live regions after shopping cart changes
And how to markup the shopping cart as a menu widget in general

The following part of this article will be about the latter.

Details/Summary

When you read my last #accessibleapp article you will notice that I added an update regarding the WAI ARIA Authoring Practice I based my "vue-menu-button" on. The situation is not very clear, there are many experiences with and opinions on this subject. Until there is more user data available on this subject I decided to remove the menu/menu-item pattern from the account button and use a more simple solution instead: details and summary (I wrote a small note on how GitHub is using these elements for their menu structure - although relying on the menu/menuitem pattern). Especially regarding the fact that I - until now - only added links to that specific menu.

So, my next step was to implement <details> and <summary> in Vue. Which was very easy, due to the elements on-board toggling behavior. Here is the structure:

<details ref="details">
    <summary>I'm the trigger</summary>
    <div class="content">
        Here goes the content that is initially hidden
        but visible once details has the open attribute
    </div>
</details>

What happens on the HTML side of things is: once the summary element is activated (via click, touch, enter, space-bar) the open attribute is added to the details element as a whole. To achieve a "menu look" I only had to style the content that I intended to use as "menu content"

[open] .content {
  position: absolute;
  background-color: #ffffff;
  min-width: 320px;
  padding: 10px 0;
  border: 1px solid #2368a2;
  animation: slide-down 0.2s ease;
  box-shadow: 4px 4px 6px 0 #6665654d;
}

The summary, element, when unstyled, includes a caret. You can remove it via:

summary {
  list-style: none;
}

One last thing I added was a feature which I had built for the menu button: that a click outside my details/summary construct removes the open attribute and, therefore, closes the menu. This was the first "real" part where I had to deal with Vue and JavaScript, and it was as easy as:

<script>
export default {
  name: "NavigationMenu",
  created() {
    // On components creation, add click event listener to document
    document.addEventListener("click", this.documentClick);
  },
  methods: {
    documentClick(e) {
      // Get the details element
      let el = this.$refs.details;

      // Check if click happend inside component
      let target = e.target;

      // If not, close
      if (el !== target && !el.contains(target)) {
         this.$refs.details.removeAttribute("open");
      }
    }
  }
};
</script>

I will use this approach both for the account (which will contain links) and the shopping cart button. Thats why I made a component out of the structure, styling and "behavior" I described in this article.

You can see the aforementioned buttons in action on https://vuejs.accessible-app.com. Actually, there is a lot more to see (and to hear). But as I wrote above - I will explain the other features of the shopping cart in separate articles.

For now, let's wrap up. Once I find the time, it's likely that I release my light Vue wrapper for details/summary as a discrete component, that also deals with the browser support by adding a polyfill. But at this point in the example app's life using details/summary for these menu purposes feels right overall.

Progressively enhanced menu buttons with details/summary

Marcus Herrmann — Fri, 01 Feb 2019 15:00:51 +0000

While researching for the accessible approach to menu buttons in Vue this week, I couldn't help myself but to open my browser's dev tools on every "menu button" sighting I came across, curious how the respective team or developer implemented it.

The concept of a "menu" of any kind is often found in profile dropdows. Some websites decide to not use a semantic menu at all, "just" showing a div or list on click and releasing its content into the tab order, (dev.to, for example).

And there is GitHub's approach that uses the details and summary element for a menu, making the whole construct work even without JavaScript (in nearly every browser). Here's the birds-eye view of their approach:

<details>
    <summary>Click me</summary>
    <details-menu role="menu"> <!-- a custom element -->
        <li><button type="button" role="menuitem">Agnetha</button></li>
        <li><button type="button" role="menuitem">Björn</button></li>
        <li><button type="button" role="menuitem">Benny</button></li>
        <li><button type="button" role="menuitem">Anni-Frid</button></li>
    </details-menu>
<details>

I won't try to explain it any further - because:

GitHub put their approach on, well, GitHub: the <details-menu> custom element
Mu-An Chiou, Web Systems Engineer at GitHub, not only did a presentation about their technique (link to slides), but supplied a details on details document with further links and anecdotes
Mu-An is approachable on Twitter, offering to chat about her approach

Accessible menu buttons in vue.js

Marcus Herrmann — Wed, 30 Jan 2019 19:33:36 +0000

tldr; https://github.com/marcus-herrmann/vue-menu-button

My approach is to first map common widgets and scenarios in Single Page Apps to accessible-app.com (for this reason modal dialogs and routing are already part of the demo application). What you also see very often are menu buttons. Now Heydon's right about this - when talking about menu buttons, the terminology soon becomes blurred. There are some "menus" or "dropdowns" out there that will show navigation items on click or hover (sometimes the triggering entity is a navigation item itself) - and there is the Menu Button Design pattern" from WAI-ARIA Authoring Practices 1.1. The latter definition of the term is discussed below.

ARIA Menu Button chapter lists two examples of what they mean by that:

Navigation menu buttons
Action menu buttons

Differences

The difference between these two approaches lies in the content of the menu. Navigation menus contain links:

The menu items are made from HTML links and maintain their HTML link behaviors. That is, activating a menuitem loads the link target, and the browser's link context menu and associated actions are available.

While Action menus contain actions (duh). To my understanding, these menu actions have things in common with buttons (e.g. they don't change the URL), but lack many of their advantages (e.g. listening on "Enter" and "Space" key events, automatically being part of the tab-order).

Similarities

In standard navigation menus we often see the use of role="menu" and role="menu-item". In this context, these uses are wrong, in Menu Buttons however correct (again, see the ARIA practice). This leads to a general structure that both Navigation menu buttons and Action menu buttons share:

button
 menu
     menu-item
     menu-item
     menu-item

Now we have to convey relationships between this items. ARIA requires for menu button to have

aria-haspopup="true" to indicate the button opens a menu
aria-controls="IDREF" to refer to the element controlled, in our case, the menu
aria-expanded="true" when the menu is open (aria-expanded="false" or the removal of the attribute altogether communicate that the menu is closed

This gives us the following HTML for the button and the menu wrapper:

<button aria-haspopup="true" aria-controls="the-menu" aria-expanded="false">
    Open me
</button>
<ul id="the-menu" role="menu">
    (menu-item)
    (menu-item)
    (menu-item)
</ul>

I left out the markup for the menu-items deliberately, because it has to do with the decision where we want to build a Navigation menu button or Action menu button.

For Navigation menu button items it is:

<li role="none"><a role="menu-item">About Page</a></li>

Whereas for Action menu items:

<li role="menu-item" tabindex="-1">Print this page</li>

At first glance, this is odd. But when you look closer, you'll see why it all makes sense:

The list with the id "the-list" is semantically speaking no list anymore because it has got role="menu". So, henceforth, it is a menu
A menu expects to have menu-items as its children. Therefore we strip the li of its semantic meaning as listitem:
- When it is a Navigation menu-item, we set the li's role to none, but give the anchor element inside it the role of menu-item
- When it is an Action menu-item, the li becomes a menu item. Also with the tabindex attribute we make sure we can set focus the item programmatically (more on that below).

Keyboard accessibility

Now that we established a menu - we essentially promised that the user can use it like one. And by "using" I mean that our menu reacts to the following keystrokes

ESC/Enter: closing the menu, setting focus to menu button
Up Arrow: Moves focus to the previous menu item, or: If focus is on the first menu item, moves focus to the last menu item.
Down Arrow: Moves focus to the next menu item, or: If focus is on the last menu item, moves focus to the first menu item.

ReachUI's approach

Having read and studied the ARIA Authoring Practices I searched form menu button implementations in React and Vue. I found many pretty components with fancy animations and all, but all of them lacking both the menu button semantics and keyboard behaviours. Let's just assume that these scripts don't want to be menu buttons at all.

Luckily there's React's ReachUI and its creator Ryan Florence wants to supply a proper menu button component (find the "MenuButton (Dropdown)" component here). When I looked in its code examples I found something very interesting - a mix between Navigation and Action menu button:

<Menu>
  <MenuButton>
    Actions <span aria-hidden>▾</span>
  </MenuButton>
  <MenuList>
    <MenuItem onSelect={() => alert("Download")}>Download</MenuItem>
    <MenuItem onSelect={() => alert("Copy")}>Create a Copy</MenuItem>
    <MenuItem onSelect={() => alert("Mark as Draft")}>Mark as Draft</MenuItem>
    <MenuItem onSelect={() => alert("Delete")}>Delete</MenuItem>
    <MenuLink
      component="a"
      href="https://reach.tech/workshops"
    >Attend a Workshop</MenuLink>
  </MenuList>
</Menu>

My vue-menu-button

This is an interesting approach I decided to emulate for Vue and especially for #accessibleapp. As of now, you can see the said button in use on vuejs.accessible-app.com ("Account") and find the code for vue-menu-button on GitHub.

Things I borrowed from ReachUI's component

When your focus is on the button element and you hit either Up Arrow or Down Arrow the menu opens and movies focus to the first or last menu item respectively.
The API of the component: If you want an action item, you can use <MenuItem /> in Reach or <menu-item /> my Vue component. If you want to place a link (or Navigation list-item) you can write <MenuLink component="a" href="https://reach.tech/" ... > in Reach and you can use a <menu-link /> component in my script. Bonus: you can place a <router-link> in there, and it still works!

So here's the template of Accessible App's AccountButton component:

<template>
  <menu-wrapper>
    <template slot="menu-button"
      >Account
    </template>
    <template slot="menu-content">
      <menu-link>
        <router-link to="/orders">Past Orders</router-link>
      </menu-link>
      <menu-link>
        <router-link to="/settings">My Settings</router-link>
      </menu-link>
      <menu-item @click="doSomething">Clear my Shopping cart</menu-item>
    </template>
  </menu-wrapper>
</template>

I'm somehow aware that my script could be improved regarding its options and configuration (if you have suggestions - please contribute!). But what I wanted to do first is to show a way of how to write such a component in a semantic way, to listen to key events, to offer a reasonably API, and for example, how to solve the aria-controls reference. I hope I succeeded. But even if I didn't, I immersed myself intensively in the Menu Button design pattern during my research - and that alone was worth the effort.

Accessible routing with vue.js

Marcus Herrmann — Fri, 11 Jan 2019 19:27:58 +0000

Routing is an integral part of a Single Page Application, and therefore for my side-project accessible-app.com. Since it's so central for Single Page App inclusiveness it is the first of the committed features for version 1 of Accessible App I decided to tackle. Also, from all of the big JavaScript frameworks I want to cover in this project, I am most familiar with Vue. So I tried to use the official Router, vue-router, in an accessible way.

As I mentioned before, React is ahead of Vue when it comes to plug-and-play solutions for and documenting of accessible solutions in their framework. One of the (aiming to be) ready-made solutions is Reach UI, specifically Reach Router by Ryan Florence. On Reach Router's product page he summarizes why developers must be aware of the accessibility problems that come with not refreshing the page as a whole:

Whenever the content of a page changes in response to a user interaction, the focus should be moved to that content; otherwise, users on assistive devices have to search around the page to find what changed – yuck! Without the help of a router, managing focus on route transitions requires a lot effort and knowledge on your part.

When you use Reach Router in your React app it takes care of the managing focus part by manually setting the focus to the container of the newly loaded contents. This is great, but for my Vue routing approach, I wanted to make it configurable where focus is being sent to. You should be able to send the focus for example to a headline within the loaded content (as Google's Rob Dodson summarizes it concisely, or simplyaccessible.com explains this in detail using Angular).

Accessing the focus target

We can mark the node where we will send the focus onto after route transition with a reference. Meaning: putting the ref attribute on it and then accessing it (learn more about accessing the DOM with $refs here). An example:

<h2 ref="focusTarget">Focus me</h2>
// Get the element in Vue with this.$refs.focusTarget

Now that we got the reference to the focus target we must find out when a route transition happened, and hook into that event. You can use a watcher for this. But you have to make sure that you wait for the DOM to have actually changed. This is what Vue.nextTick is for:

new Vue({
    router,
    watch: {
        $route: function() {
            this.$nextTick(function () {
            // $nextTick = DOM updated

            });
        }
    }
}).$mount('#app');

Wait for it...

One other thing is to add a delay before running the actual focus code. This apparently stems from Voice Over failing to set focus on changed DOM nodes in iOS 7 and earlier. Although this appears to be fixed in Version 8 - since I can find new information on the topic, I'll add a delay.

Now for the central focus part. At first, we're looking for the focusTarget ref. If your route watcher can't find it, our focus target will be the container where content will be loaded into after route transition. Vue Router calls it <router-view>. To make this fallback easier to grab, we will add a reference to the router view like this:

<!-- Here be <router-links />'s -->
<router-view ref="routerView"></router-view>

But back to JavaScript:

// Get component's "routeFocusTarget" ref.
// If not existent, use router view container itself
let focusTarget =
    (this.$refs.routerView.$refs.componentFocusTarget !== undefined)
        ? this.$refs.routerView.$refs.componentFocusTarget
        : this.$refs.routerView.$el;

Before we finally can set focus on the focus target we actually have to make sure that we can set focus programmatically to it (because usually, just interactive elements like buttons, links, or form inputs are focusable).

focusTarget.setAttribute('tabindex', '-1');

GDS, the team behind gov.uk has discovered that a "stray" tabindex on a wrapping container - in their case, the <main> element, which was a hack around a browser bug anyway, could cause some issues. Therefore, we're removing the tabindex just after eventually setting focus:

// Focus element
focusTarget.focus();

// Remove tabindex from focustarget.
focusTarget.removeAttribute('tabindex');

Putting it all together

I've prepared a CodePen demonstrating this where I put all of the parts mentioned above together. In this example, the "route target" components are very simple - two of them have their componentFocusTarget explicitly set to their first headline, one of them to their general container DOM node, and one of them has no such ref at all. But in any case - focus is being dealt with after a route change. For debug and display purposes I made the focus visible with a red border. But moving focus on route change alone is not enough to achieve accessible routing. Once you change the URL in your Single Page App, you have to adjust the document's title as well.

Demo

This way we prevent the situation described by Ryan Florence above - that a user of assistive technologies interacts with a route link, focus stays on said link, although parts of the DOM has changed, and they need to actively search for the changes.

Native focus management in vue-router

I filed a feature request on the focus subject in the official vue-router repo. Vue core member Eduardo San Martin Morote replied:

Thanks for bringing up the discussion. I've been looking at reach router for some time regarding this and it's something we should be able to provide

Not having to add strategies like the one mentioned above, and instead find this already built-in into vue-router would indeed be awesome!

In the end, I am very curious what you think of this solution. Even to step back a bit - the focus management pattern for SPA routes presented here is a best practice, but all assumptions surrounding it should be tested (and it would be great if Deque Systems, Marcy Sutton, and the accessibility community could conduct such a test). Until then, please don't hesitate to tell me what you think of this routing and focus management approach - and where it can be improved.

Update: Putting this technique into an example app

I researched this routing strategy for #accessibleapp, a side-project where I collect techniques for building inclusive JavaScript web apps (in React, Vue and Angular). To supply a tangible example I built an example app called "Accessibooks", and you can find the Vue implementation at https://vuejs.accessible-app.com

DEV Community: Marcus Herrmann

Accessible Overflow

Rock'n'Scroll

Overflow and Focus

Ensuring a coherent experience across browsers

Demos and Links

Twenty inclusive strategies for building web apps in 2020

Fata Morganas in Accessibility

No. 1: Using aria-role="feed" solves accessibility issues for all users

No. 2: Detecting screen readers in CSS with the speech media query

No. 3: Using the <dialog> element for perfectly accessible modal windows

No. 4: Using aria-label as a means to describe everything

Using JavaScript framework powers for good

There are advantages

Developer experience

Externals: usable, internals: accessible

Making accessibility hard to circumvent

Use all of the framework's functionality...

...and its design approach

Automate...

...or use props in a smart way

Both sides of the (app) story

Conclusion (for now)

What are the accessibility challenges when building web apps?

Click targets that are not links

But the styling

But I could use a link with href="#" to achieve the same thing

Inputs and Controls

AJAX - Changing and loading things asynchronously

An example

Solution strategies

Route changes

Best practices for accessible routing:

Conclusion

Accessible animations with Vue

Using summary/details as a menu

Details/Summary

Progressively enhanced menu buttons with details/summary

Accessible menu buttons in vue.js

Differences

Similarities

Keyboard accessibility

ReachUI's approach

My vue-menu-button

Accessible routing with vue.js

Accessing the focus target

Wait for it...

Putting it all together

Demo

Native focus management in vue-router

Update: Putting this technique into an example app

No. 1: Using `aria-role="feed"` solves accessibility issues for all users

No. 2: Detecting screen readers in CSS with the `speech` media query

No. 3: Using the `<dialog>` element for perfectly accessible modal windows

No. 4: Using `aria-label` as a means to describe everything