Imagine you’re holding your phone, walking down the street, and you accidentally bump it against your leg. Suddenly, your app thinks you’ve shaken it into submission and deletes your entire shopping cart. Or maybe you’re trying to scroll, but the device interprets your hand tremor as a “shake to undo” command.
This isn’t just a quirky feature gone wrong; it’s a potential accessibility nightmare. Enter WCAG 2.5.4: Motion Actuation.
Comments closedThe <abbr> element stands for abbreviation. The idea behind this is you provide the abbreviation of the word or phrase, then use the title attribute to display the whole name or phrase.
<p>You need to pay your taxes to the <abbr title="Internal Revenue Service">IRS</abbr> for many years.</p>The problem with this is that the <abbr> is not an interactive element. You cannot tab to it. It will be read just like any other word in the sentence. If you mouse over the element, you see the title. But if you use keyboard there is no way to expose it.
Then there are screen readers. Most screen readers will not announce this title.
It’s better to fall back to the old newspaper styling where you say the whole phrase the first time followed by the abbreviation in parenthesis. From there forward, you can use the abbreviation.
Take a look at the testing Adrian Roselli has done on this.
Comments closedWe all navigate the internet and computers in different ways. Some use screen readers, others keyboard, and some people by voice. Success Criterion 2.5.3 was created to support these diverse methods. While it helps all users, it was created to address using voice control because typing is a struggle for the user. On the screen is a button that clearly says “Submit Order.” You speak the command: “Click Submit Order.”
Nothing happens.Or worse, it clicks the wrong thing.
Comments closedLast 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 closedThis applies to browser behavior as well. I’ve been encountering a significant number of sites recently where the site tries to offer the user ways to make the site more accessible. Sometimes these are part of an overlay or widget providing accessibility “fixes” and sometimes they are part of the core code. In both cases they are taking the wrong approach to implementing help. Let me explain why.
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 closed
