So, how do we take things to the next level? Testing your website with a screen reader is a great way to start. Let’s take a beginner’s look at what’s involved. From there, I’ll share what I found during my experimentation.<\/p>\n
Find a Screen Reader App<\/h2>\n
The first step in the process is to find a suitable screen-reader app. You may not have to go very far, as some operating systems include one by default.<\/p>\n
Mac users have access to VoiceOver<\/a>, while Windows folk can tap into Narrator<\/a>. In addition, there are several other options<\/a> available for virtually every OS. For my part, I’m going with the open-source app NVDA<\/a>. It’s free to use (supported by donations) and is among the more popular choices.<\/p>\n Regardless of the app you choose, it’s important to have a basic understanding of how it works. In addition, there may be a need to make a few tweaks beforehand. For example, you’ll want to make sure that you can understand what is being read. You might also want the software to highlight content as it is read, making it easier to follow along.<\/p>\n WebAIM has put together some handy guides<\/a> for setting up various screen readers for testing purposes. They’ll put you in a good position to see just how accessible your website is.<\/p>\n Now that you have a trusty screen reader at the ready, it’s time for testing! To get a taste of the user experience, try going through the various parts of your website via a keyboard with the screen reader enabled.<\/p>\n Some keyboard commands are more universal than others. For instance, the However, there may be some special commands that are specific to a screen-reader app. They allow for navigating between headings, landmarks such as headers and footers, etc. For that, you’ll want to check out its documentation.<\/p>\n It’s also worth noting that it takes practice to effectively navigate a website this way. The first few tries can be a bit awkward. But once you get the hang of the various commands, things should become more intuitive.<\/p>\n Just to clear the air \u2013 I’m not an expert screen reader user. My knowledge is rudimentary at best. But my experience with NVDA has been enlightening.<\/p>\n I used a few pages of my business website as the testing ground. And what I found weren’t necessarily major flaws. The text could be read and the site could be navigated.<\/p>\n Rather, I discovered some annoyances \u2013 things that would understandably frustrate users. Let’s review a few examples:<\/p>\n In an interview<\/a> with accessibility expert Taylor Arndt, she mentioned carousels\/slideshows as features that can hurt accessibility<\/a>. Testing with a screen reader brings that to the forefront.<\/p>\n The automated carousel I used was navigable but had a nasty habit of announcing itself each time the next slide came into view. That made it very difficult for the screen reader to get very far into other sections of the page before being interrupted.<\/p>\n I found a simple enough fix. The WordPress slider plugin I utilize (Soliloquy) has an option to change the ARIA live region<\/a> to a less aggressive setting. This, coupled with using manual navigation for the carousel, got rid of the nuisance.<\/p>\n Using the Blog post listings were the main culprit. Both the post title and featured image The sticking point is that the WordPress post listings block I used doesn’t have an option for leaving empty ALT attributes. Thus, a workaround may be required.<\/p>\n Building websites that adhere to WCAG standards feels satisfying \u2013 and it’s what we’re supposed<\/em> to do as web designers. But checking off boxes on a to-do list doesn’t tell the full story.<\/p>\n Getting a better understanding of how others will experience your work requires a little extra effort. Testing with a screen reader provides a path for gaining more insight. And while this is by no means a complete guide, I hope it helps to pique your interest and experiment.<\/p>\n As I found, even if an item is considered to be accessible by the letter of a standard, that doesn’t mean it’s easy to use. This is why it pays to dig a little deeper. It may be the difference between a site that’s merely usable or one that provides the best possible experience.<\/p>\n Note:<\/strong> As mentioned above, I’m a novice when it comes to this technology. If you have screen reader tips to share, feel free to reach out to me via Twitter<\/a>.<\/p>\n The post How to Start Testing Your Website with a Screen Reader<\/a> appeared first on Speckyboy Design Magazine<\/a>.<\/p>\n Source: Specky Boy<\/p>\n![\"The](\"https:\/\/i0.wp.com\/speckyboy.com\/wp-content\/uploads\/2022\/04\/test-with-a-screen-reader-01.jpg?resize=900%2C400&ssl=1\")
<\/p>\nGetting Around<\/h2>\n
TAB<\/code> key will take you to various links and form controls, while ENTER<\/code> will take you to a link’s destination. Most seem to use the arrow keys to move from line to line.<\/p>\n![\"The](\"https:\/\/i0.wp.com\/speckyboy.com\/wp-content\/uploads\/2022\/04\/test-with-a-screen-reader-02.jpg?resize=900%2C400&ssl=1\")
<\/p>\nMy Experience with a Screen Reader<\/h2>\n
A Slider That Interrupts<\/h3>\n
Repetitive Text<\/h3>\n
ALT<\/code> attribute with images is a common piece of accessibility advice. But for purely-decorative images, providing descriptive text can be redundant. I ran into this on a few different occasions.<\/p>\nALT<\/code> attributes were identical \u2013 meaning the screen reader read them twice. The result is that even a relatively short post listing makes for a painful UX.<\/p>\n![\"A](\"https:\/\/i0.wp.com\/speckyboy.com\/wp-content\/uploads\/2022\/04\/test-with-a-screen-reader-03.jpg?resize=900%2C400&ssl=1\")
<\/p>\nDiscover How Website Accessibility Works in Practice<\/h2>\n