Last week I wrote about gestures and pointers. This week we look at the next criteria, Pointer Cancellation. I mentioned that we wanted events to fire on the “Up” or “release” action. And that’s what this criteria is all about. We need to make sure that if a user creates a down event on a control, we need to allow them to cancel. Let’s look at the methods used.
Comments closedIf you’ve been following my work or this blog for a while, you’ll know I’m always referencing that authors need to support both mouse users as well as keyboard users. What I haven’t mentioned much of is touch. Touch devices have given us a number of different modalities to interact with applications and the web. The problem arises when users don’t have the ability to touch the screen, or only have a single pointer when multiple are needed. Or perhaps they can’t perform the gesture. This is the point of this success criteria, providing an alternative for those users. Let’s check out how we do this.
Comments closedModern dynamic websites use layers of content on a page. We have tooltips, popups, dialogs, menus, navigation, and modals that bring more functionality by using these layers. But they can introduce a problem for keyboard-only users when focus can fall on content underneath. Let’s explore how this can resolved.
Comments closedDisabilities come in all sorts. So do users. Some users can manipulate a mouse. Some rely on keyboard alone. Others have assistive technology. When you use a mouse, where your mouse is located is visible. This lets the sighted mouse user know what they are clicking on and where the focus is. Keyboard only users need something else. Let’s get into the details of what is needed.
Comments closedHeadings and labels need to describe the content they are identifying in the content. This means when you have a H1 is should describe the page as a whole. Labels need to describe the data they are collecting. Seems simple. And usually it is. Let’s look at some examples of when it isn’t as clear.
Comments closedIt’s been a busy week in my house, so I’m going to keep this quick. One of the issues I often see flagged by other accessibility testers is that something doesn’t work with keyboard navigation. The vast majority of times I revisit these, it turns out the tester doesn’t fully understand how screen readers work. I want to highlight a few items for folks.
Screen readers typically have 3 main modes. The virtual browser, forms, and application.
The virtual browser is when the screen reader technology is intercepting the keyboard input and uses that to execute a function in the browser for you. When we press tab we jump to the next active item. Pressing the down arrow will read the next line, chunk, or set number of characters in a paragraph. Here’s a short list of common commands:
When a user encounters a form element, the screen reader should automatically shift to the forms mode. There usually is ab audible sound to indicate this. This mode moves the screen reader out of the way to interact directly with the page via the keyboard. This limits how to navigate to using only the Tab and Shift keys to move among the active elements in the form.
In this mode you need to have the role=”application” and then the screen reader again gets out of the way of the keyboard. However, even if you use active controls navigating between them is completely up to the author. They will work with Space & Enter to activate, but the author really needs to define the navigation scheme and controls to use the tool.
Don’t flag an issue for not being keyboard accessible with a screen reader on unless you can identify it is an application or is also not accessible without the screen reader.
There’s way more to this, but the great folks over at Tetralogical have a great screen reader misconceptions article and a full break down of commands.
Comments closedIn the physical world we understand that not everyone can climb 20 flights of stairs, so under the ADA we created rules to overcome these situations. Buildings now have commitments they need to make during construction to include ramps and elevators to access areas that someone might not be able to climb stairs. This is an example of multiple ways. Let’s review how that translates to digital spaces.
Comments closedI’ve been encountering a pattern lately of developers trying to do things right when it comes to live regions, but not understanding how they essentially work. This tip is to provide a super high level on how they function.
Leave a CommentLinks are what make the internet the world wide web. The original idea was that the internet is a set of digital documents. The link allows you to move between them. To make them as effective as they can be, we want to make them clear in what they do. Often though, the simple link doesn’t provide a clear purpose. Let’s look at what it takes to pass 2.4.4 Link Purpose (in Context).
Comments closedI’ve been doing accessibility work long enough that I can confidently say, you cannot avoid lawsuits about accessibility. What you can do is minimize your risk. If you do not have an accessibility effort going on in your company, start one. This guide will help you prioritize where you should be looking first. If you have a program going, this can help focus your efforts into where most lawsuits look first.
1 Comment
