A11ying with Sanna - Testing for accessibility A little testing workshop

Testing screen readers

One thing to remember is that nothing is better than having an actual screen reader user (or even plural) do the testing. When you don't use the screen reader daily, you won't be as fluent with it as someone who relies on it. That being said, there are times when you can't have access to a person who could do the testing, and then it's up to you.

In the optimal case, you would test with many screen readers and browsers. But the important thing is to test with at least one. Not all screen readers work the same, and some work better with a different browser than the other. I recommend checking out WebAIM's Screen Reader User Surveys for some data about the most popular screen readers, browsers, and devices.

Usually, keyboard and screen reader functionality go partially hand in hand. If you can access an element with a keyboard, if it's not specifically hidden from the screen readers, you should be able to access it with a screen reader as well.

Here are a few things you should at least test for:

  • Access to elements.
  • Everything that has ARIA in it. And I mean everything. Check even the most simple elements.
  • Media alternative texts. Do they make sense? Are they in the correct language? Automated testing tools can check that the text is there but that's as far as they can go.

Again, I've added some mistakes on this page for you to locate. What kind of errors can you find?

Want to do more testing with a screen reader?

If you didn't get enough, you can visit my accessibility site for more demos. A few demos to mention are:

Or you can take a look at something you've created or been a part of creating. Real-life examples are always the best to help you see potential issues in how things are done.

Some basic form controls to test

Choose your favorite
Choose your favorite

Menus

Listen to the menu functionalities. Here ARIA really makes a difference for the user.

Cards

With cards the most common mistake we make is to decide for the user what content is important in the card. The accessible name should contain the visually shown text. And this means all of it.

One reason we make the mistake of restricting the amount of content is that we feel it will be too heavy for the listener. But we often also forget that screen reader users listen to the content with much faster pace than we do.

One thing to know is that VoiceOver behaves a bit different in Sonoma than it does in Ventura!

One recommendation that is given in accessibility audits is to have the image below the heading. That way it is clear for assistive technology users that this image is related to the heading.

If possible, this can be done by visually moving the image. So the structure in the DOM could be heading, text, image and then you can move the image with CSS to the correct place.

If you read this far, great! Now pause for just a moment to think how you feel about these types of cards or content teasers etc. Should the whole element be clickable or just the heading or a link button? There is no right or wrong answer, only preferences.

Language

The page language must be correct, CMS like Drupal usually handles it automatically. But for any text in another language, you need to specify the language with the lang attribute. Tämä teksti on suomea.

When the language is marked correctly, the screen readers can read it correctly. Note that some screen readers require you to install language packages separately. So if your screen reader doesn't switch language, that might be the reason. You only need to make sure you mark the language correctly, the users worry about the rest.

Screen reader usage

Choose a screen reader you want to test with. Our laptops have VoiceOver in them you can use. If you've never used a screen reader before, let's start from the very beginning.

  1. Take a look at the screen reader settings. If you'll use VoiceOver, they are located under Accessibility > VoiceOver
  2. You can find a VoiceOver Training on the settings page, but don't focus on it now. VoiceOver Utility has much more VoiceOver settings. What you want to do now is to check that you use the VoiceOver modifier you prefer. VoiceOver modifier is shortened in a lot of guides to VO.
  3. Learn to toggle VoiceOver on and off. You can do it in the settings or use keyboard shortcuts.
  4. Press VO + shift + F11. What happens?
  5. Press VO + a. What happens? To stop, press crtl.

Now on to the actual usage:

  1. I've hidden some mistakes on this page. Check the examples with a screen reader.
  2. Open up the VoiceOver rotor: VO + u. You can switch between different lists with the arrow keys (there are settings to define what lists are available in the Web settings, where the last tab is Web Rotor).

    With the rotor you can check for page headings and their levels much easier (you can press a number to show only that level of headings), you can check the page links and landmarks among many others. Test the different options available to you in the rotor and see how the results are shown.

Some homework for you:

  1. Familiarise yourself with desktop VoiceOver settings (or the screen reader of your choosing). You can tweak them to your liking.
  2. Apple has a lot of good instructions for VoiceOver on all their devices, those can be helpful as well, at least check them out so you know where to find them if you need them.
  3. Familiarise yourself a bit with whatever screen reader is available on your phone. iOs has VoiceOver and Android has TalkBack.
    1. Learn to turn it on an off.
    2. Learn how you should move from one element to another and how you can activate elements.
    3. Learn to start and stop reading content.