Month: August 2021

In the ways I monitor accessibility, it is clear that there is a greater awareness of the topic and more effort being put into making technology accessible. This is good.

Yet, the vast majority of accessibility policies still fail at what for me is one of the most fundamental needs. Specifically what is a user supposed to do when an accessibility issue is encountered?

I’m using the term “accessibility policy” here as a broad definition. It is more than just the words and phrases that appear in some document posted on a web site or other location. In theory those are just the outward signs of a range of processes and more that lead to an organization being able to actually have an accessibility policy.

I recognize that definition can be a stretch. In fact, often the reason for the failure I describe here is because the “accessibility policy” is just words and not something embedded throughout the organization.

Far too often, if a policy tells a user what to do, those instructions are geared toward how to report an issue. While this is obviously helpful, it does nothing to solve the user’s immediate need. You are asking the user to invest time in reporting an issue at the very time that user is likely the most frustrated with an experience you have created.

For me, a robust accessibility policy will go beyond this. The policy should not simply ask the user for information. It should offer an alternative way, when at all possible, for the user to get the information or task completed they were attempting when they hit the barrier.

One of my favorite questions, even today, is still why? Why are you posting your accessibility policy for example? Is it to comply with a government regulation, to provide users with information or what?

Similarly, as a user, why do I look for accessibility policies? In my case it is typically to find how I should report issues but also to see if the organization has some alternative way of task completion when I hit a barrier. It can also serve as a reflection of the organization’s overall philosophy on accessibility.

As much as I wish the frequency of accessibility issues I encounter was reduced, I’m realistic enough to know that’s not likely any time soon. I can come to grips with that at some level but not the leading a user with no alternative. That is where organizations should look within and recognize accessibility issues are going to happen and users need to be given paths to success when they do.

Leave a Comment

Yesterday I read about the team at WebAIM releasing a version of their popular Wave toolbar as an Edge browser extension. I’m very familiar with the tool so wanted to see how it behaved in Edge.

On the page with details about the extension, there is a section talking about how to use the tool. I noticed that it said you could press ctrl+shift+u, so after installing for Edge that’s what I dit. I pressed ctrl+shift+u and imagine my surprise when the page I was on started to be read aloud.

This is one of those things lumped into the category, I knew this but kind of forgot it in the moment. Ctrl+shift+u in Edge is the hotkey to do exactly what happened, that is start reading the current web page with Edge’s Read Aloud feature.

I had also noticed in the instructions for using the Wave toolbar a comment saying you could change the shortcut in Edge on the Manage Extensions page. My days of working on web browsers exclusively have long past so I wasn’t actually aware you could change the shortcuts assigned to extensions in Edge. I certainly am now. I wanted to share how you can quickly do this when using a screen reader, although the same basic process works without a screen reader as well.

The fastest way to get to the Manage Extensions page is to press ctrl+l on Windows or CMD+l on a Mac and enter edge://extensions in the browser address bar. This opens an Edge page showing you all the extensions yu have installed with options for the extensions.

Initially I was a bit stumped at this point because I was not finding anything about changing keyboard shortcuts. I was using the JAWS screen reader at the time and as with any web page, the Virtual PC cursor was on.

I’ll spare most of the details about how screen readers work, the different modes and more for now and hopefully talk about that in a separate posting. The short version of what I discovered is that there is a tree-view on this page you can use between listing extensions and managing the keyboard shortcuts for those extensions. You need to use that control and change to the Keyboard Shortcuts entry.

In the default way Narrator and NVDA present this page, both options from the control are shown in the Scan Mode (Narrator) and Browse Mode (NVDA) view. You can press enter on the choice you want. With the Virtual PC Cursor on, JAWS currently shows a nameless tree-view you need to press enter on to turn Forms Mode on and then adjust the control. You’ll need to turn Forms Mode off as well. With Forms Mode on, the values as you arrow up and down are properly read so Arrow down once to Keyboard Shortcuts and press enter. As of now, I did not try this page with VoiceOver on the Mac.

Once you change the Manage Extensions page to show keyboard shortcuts, there are a series of edit boxes where you can assign or adjust the keyboard shortcuts being used. These behave like typical edit boxes. Since I just learned about this functionality, my information may not be 100% accurate but I believe you can use either Control or Alt along with a shortcut key key here. I also believe you can add shift to either control or alt. For example, I made my shortcut for activating the Wave toolbar ctrl+shift+w. When a shortcut key has been assigned, a clear button becomes available if you want to remove it.

As a side benefit of all of this, I did discover that Accessibility Insights, an extension I use frequently, allows for multiple keyboard shortcuts for different functions of the tool.

Leave a Comment